{"text_format":"1","workbook":"xlsx","n_sheets":3,"sheets":["TDoc_List","CR_Packs_List","Parameters"],"not_rendered":{"charts":0,"images":0,"macros":1,"external_links":0,"defined_names":5,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"TDoc_List","index":0,"n_rows":703,"n_cols":31,"rows_kept":703,"cut":false,"hidden":false,"merged":[]}
["TDoc #","Title","Source","Contact","Contact ID","Type","Type supplement","For","Abstract","Agenda item sort order","Agenda item #","Agenda item description","TDoc sort order within agenda item","TDoc Status","Reservation date","Uploaded","Is revision of","Revised to","Release","Spec #","Version","Related WIs","CR #","CR revision #","CR category","TSG CR Pack","Reply to","To","Cc","Original LS","Reply in"]
["S2-151432","Draft Agenda for SA WG2#109","SA WG2 Chairman","Frank Mademann",6821,"agenda","","","The meeting agenda.","1","2","Approval of the agenda",10040,"Revised","2015-05-04T13:12:03.540","2015-05-19T14:20:00.473","","S2-151873","","","","","","","","","","","","",""]
["S2-151433","Draft Report of SA WG2 meeting #108","SA WG2 Secretary","Maurice Pope",648,"report","","","Draft Report version 0.1.0rm of meeting #108 for approval","4","3","Meeting reports",10060,"Approved","2015-05-04T13:12:03.553","2015-05-19T15:42:48.173","","","","","","","","","","","","","","",""]
["S2-151434","LS from GSMA PSMC: LS on VoLTE Roaming Architecture","GSMA PSMC","Itsuma Tanaka",38539,"LS in","","","GSMA Product and Services Management Committee (PSMC), Network 2020 Programme and related Working Groups have been investigating a new VoLTE roaming architecture option, 'S8 Home Routed (S8HR)'. PSMC would like to inform 3GPP that PSMC endorsed S8HR as a candidate for VoLTE roaming, subject to issues (inclusive of Lawful Intercept, Emergency Call, SRVCC, and others) being resolved by 3GPP. PSMC would like to have initial feedback by PSMC#135 meeting in July 2014. Action: PSMC would like to kindly seek support from 3GPP to determine the solutions for issues identified in the GSMA (to be provided under a separate LS from GSMA NG), and inform us of the anticipated completion date.","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10140,"Treated","2015-05-04T13:12:03.553","2015-05-04T13:13:51.053","S2-150704","","","","","","","","","",null,null,null,"PSMC 131 Doc 201","S2-152117"]
["S2-151435","LS from CT WG1: Reply LS on PLMN reselection for ProSe","CT WG1","Maurice Pope",648,"LS in","","","CT WG1 would like to inform SA WG2 that CT WG1 has discussed the options identified by SA WG2 to address the multi-carrier scenario across PLMNs, and intends to specify Option 2. Action: CT WG1 kindly asks SA WG2 to take the above information into account.","13","5.1","3GPP Packet Access Maintenance",10400,"Noted","2015-05-04T13:12:03.570","2015-05-04T13:13:51.100","S2-150709","","Rel-12","","","","","","","",null,null,null,"C1-150886"]
["S2-151436","LS from CT WG3: LS on Enable MB2 authorization","CT WG3","Maurice Pope",648,"LS in","","","CT WG3 have discussed the authorization of the GCS AS for making use of the supported procedures over the MB2-C interface, such as TMGI allocation/deallocation and MBMS bearer procedures. It is required that the BM-SC per supported procedure mentioned above determine whether the GCS AS is authorized to make use of this procedure or not. The mutual authentication between the GCS AS and BM-SC over MB2-C is defined in TS 33.246 Annex N. Once the involved nodes are authenticated it is assumed that a secure connection is established between these nodes. The nodes are also authorized in the security domains to communicate with respective node. 1. CT WG3 kindly ask SA WG3 if there is a need to provide an additional mechanism to authorize the application server over the MB2-C interface? 2. CT WG3 kindly ask SA WG3 if a new proposed AVP to convey the identity of the GCS AS for authorization purposes within MB2-C Diameter procedures towards the BM-SC can help to authorize the GCS AS in","13","5.1","3GPP Packet Access Maintenance",10690,"Noted","2015-05-04T13:12:03.587","2015-05-04T13:13:51.147","S2-150711","","Rel-12","","","","","","","",null,null,null,"C3-150424"]
["S2-151437","LS from CT WG3: LS on Flow ID supplied by GCS AS","CT WG3","Maurice Pope",648,"LS in","","","CT WG3 has discussed the stage 3 impacts of CR 55 against TS 23.468 agreed by SA WG2 in their recent meeting in San Francisco (S2-144533). In this CR, SA WG2 adds the option for the GCS AS to provide the Flow ID in the Activate MBMS Bearer Request. The reasoning of that CR argues that this is required to enable location dependent services. This issue has already been discussed in a joined session between SA WG2 and CT WG3 in Phoenix (see S2-141843, Question 5). At that time, CT WG3 argued that 'TS 23.246 states that Flow Ids are assigned by the BM-SC. Flow Ids seem to have no fixed configured meaning in the RAN but are rather dynamically allocated. They are used if the same service (as identified by TMGI) requires different content to be delivered to different service areas. It thus appears unclear what benefit the GCS AS would gain from providing Flow Ids. To the contrary, allowing two network entities to allocate identifiers from the same range bears the risk of conflicts a","13","5.1","3GPP Packet Access Maintenance",10710,"Treated","2015-05-04T13:12:03.600","2015-05-04T13:13:51.210","S2-150712","","Rel-12","","","","","","","",null,null,null,"C3-150446","S2-152069"]
["S2-151438","LS from GERAN WG2: LS on extended DRX in idle mode","GERAN WG2","Maurice Pope",648,"LS in","","","GERAN WG2 is studying power savings for MTC devices within the scope of two ongoing study items, Power Savings for MTC devices (FS_uPOD) and the Cellular IoT study item (FS_IoT_LC) and has identified extended DRX in idle mode as a candidate solution. In this context the SGSN will need to send a paging request to the BSS which will then be relayed over the radio interface by the BSS according to the eDRX cycle being used by the target device. However, it is unclear how the SGSN knows when to send the page to the BSS since the paging occurrence of a device within the context of eDRX may occur tens of minutes into the future from the point where the BSS receives the paging request. Furthermore, it is unclear how to guarantee that a device will not miss a page while moving between cells of the same Routing Area since the occurrence of its nominal paging group occurs at different times in different cells when these cells are not synchronized. GERAN kindly requests feedback on this","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15690,"Postponed","2015-05-04T13:12:03.633","2015-05-04T13:13:51.257","S2-150715","S2-152137","Rel-13","","","","","","","",null,null,null,"GP-150311"]
["S2-151439","LS from RAN WG2: LS reply on PLMN reselection for ProSe","RAN WG2","Maurice Pope",648,"LS in","","","RAN WG2 would like to thank SA WG2 for the LS R2-150024/S2-150664 on PLMN selection for ProSe. RAN WG2 would also like to thank CT WG1 for the LS R2-150031/ C1-150886 on PLMN selection for ProSe. The Access Stratum ProSe protocol does not consider the PLMN so far. For any of the three options RAN WG2 consider the impact to AS protocols to be minor, if any. Therefore, RAN WG2 suggests SA WG2 and CT WG1 to select their preferred option and to inform RAN WG2 about the decision. Action: RAN WG2 respectfully asks SA WG2 and CT WG1 take the reply provided above into account.","13","5.1","3GPP Packet Access Maintenance",10410,"Noted","2015-05-04T13:12:03.647","2015-05-04T13:13:51.287","S2-150724","","Rel-12","","","","","","","",null,null,null,"R2-150695"]
["S2-151440","LS from GSMA RAG: LS on VoLTE Roaming Architecture (Reply to 'LS related to Mobile VoIP IMS Roaming' / S3i150073)","GSMA RAG","Itsuma Tanaka",38539,"LS in","","","Introduction As announced in the previous communication from GSMA PSMC (PSMC 131 Doc 201, SP-150139) on a new VoLTE roaming architecture option called 'S8 Home Routed (S8HR)', Networks Group (NG) would like to provide more details on the areas that may require further technical investigation. Action: GSMA NG would like to request SA WG2 to review the items listed above, with the exception of lawful interception, and provide an analysis of the efforts that are expected to be needed to fulfil such requirements especially in terms of expected timeframe. GSMA NG would also like to learn if there are other architecture impacts that are not covered in this liaison statement.","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10150,"Treated","2015-05-04T13:12:03.663","2015-05-04T13:13:51.350","S2-151015","","","","","","","","","",null,null,null,"RAG 14 Doc 003","S2-152117"]
["S2-151441","LS from CT WG1: Reply LS on TR 26.924 Study on improved end-to-end QoS handling","CT WG1","Maurice Pope",648,"LS in","","","CT WG1 thanks SA WG4 for the LS (S4-150163/C1-150422) on TR 26.924 Study on improved end-to-end QoS handling. In the LS, SA WG4 asked CT WG1 to review TR 26.924 v0.1.7 and provide feedback where needed. CT WG1 performed the review and has no comments.","21","6.1.2","Rel-13 PCC/QoS Maintenance",11130,"Noted","2015-05-04T13:12:03.680","2015-05-04T13:13:51.397","","","Rel-13","","","","","","","",null,null,null,"C1-151042"]
["S2-151442","LS from CT WG1: LS on Service authorisation procedure based on the location","CT WG1","Maurice Pope",648,"LS in","","","CT WG1 discussed the stage 2 requirement on the service authorisation procedure based on the location as specified in subclause 5.2.1 of TS 23.303.  Step 1: The UE requests authorisation for Direct Discovery or Direct Communication or both for HPLMN or for the VPLMN or for Direct Discovery (as a 'monitoring UE' only) for some Local PLMNs from the ProSe Function in HPLMN. The UE may request a list of PLMNs to be downloaded from HPLMN ProSe Function depending on the location e.g. HPLMN or VPLMN. Step 2: The ProSe Function in HPLMN obtains authorization info from Local PLMN or VPLMN and merges with own policy. Step 3: The ProSe Function in HPLMN provides authorisation info to UE. The authorisation info provided to the UE applies to the serving PLMN, to PLMNs explicitly requested by the UE in step 1 and to PLMNs determined by the HPLMN as Local PLMNs (e.g. based on the Serving PLMN) to be available to the UE. The UE stores the authorisation information obtained from this ProSe Fu","13","5.1","3GPP Packet Access Maintenance",10440,"Treated","2015-05-04T13:12:03.697","2015-05-04T13:13:51.443","","","Rel-12","","","","","","","",null,null,null,"C1-151585","S2-152063"]
["S2-151443","LS from CT WG1: LS on network feature support for ProSe Discovery","CT WG1","Maurice Pope",648,"LS in","","","CT WG1 discussed a proposal to introduce a NAS-level indication for ProSe Discovery support in the Attach Accept and Tracking Area Update Accept messages, based on the following SA WG1 requirement: 'The operator shall be able to enable or disable the ProSe Discovery feature in its network.' During the discussion it was noted that the UE can know whether the serving cell supports ProSe direct discovery based on the information included in the SIB19. However, this mechanism cannot work well in network sharing cases because SIB19 currently does not include per-PLMN information. As a result if some of the PLMNs in the shared network have enabled the ProSe Discovery feature but some other PLMNs have not, the information in SIB19 does not enable the UE to know which PLMNs in the shared network have enabled the ProSe Discovery feature. This will lead to unnecessary ProSe signalling when the UE selects a PLMN in which the ProSe Discovery feature was disabled by the operator. Hence, C","13","5.1","3GPP Packet Access Maintenance",10510,"Treated","2015-05-04T13:12:03.697","2015-05-04T13:13:51.490","","","Rel-12","","","","","","","",null,null,null,"C1-151597","S2-152064"]
["S2-151444","LS from CT WG1: Reply LS on PLMN reselection for ProSe","CT WG1","Maurice Pope",648,"LS in","","","CT WG1 would like to inform RAN WG2 that CT WG1 agreed the PLMN selection triggered by ProSe direct communication (see the attached CRs).  Based on CT WG1 agreement, CT WG1 understand the support of AS layer is required for the PLMN selection triggered by ProSe direct communication. Thus, CT WG1 would like to ask RAN WG2 whether there is the requirement for AS layer with the following question.  Question 1: whether AS layer can report to NAS the PLMN ID(s) advertised by the cell operating in the radio resources provisioned to the UE and for each of these PLMNs, whether the PLMN provides radio resources for ProSe direct communication.","13","5.1","3GPP Packet Access Maintenance",10420,"Noted","2015-05-04T13:12:03.710","2015-05-04T13:13:51.587","S2-150709","","Rel-12","","","","","","","",null,null,null,"C1-151606"]
["S2-151445","LS from CT WG1: LS on Rel-13 MCPTT work","CT WG1","Maurice Pope",648,"LS in","","","CT WG1 would like to inform SA WG6 that, in light of the project plan proposal on Rel-13 MCPTT that was presented at CT#67 in CP-150184, CT WG1 has had some preliminary discussion about the stage 3 Rel-13 MCPTT work that is scheduled to start in CT WGs in August 2015. During the discussion, for On Network Operations, a majority of companies expressed their preference for an IMS-based architecture due to concerns about the feasibility of specifying the stage 3 for a non-IMS-based solution within only 3 CT WG1 WG meetings. Additionally an alternative deployment option could be worked on by CT WG1, but likely in a longer timeframe. For this it is essential to get informed about SA WG6 decision as soon as possible. Moreover, in order to prepare for the start of the stage 3 work on Rel-13 MCPTT, CT WG1 would also appreciate some feedback from SA WG6 on the following points: a. Per CT WG1's Terms of Reference, CT WG1 expects the application and extension of SIP, SDP and XCAP for MC","24","6.2","Mission Critical Push to Talk over LTE (MCPTT)",11390,"Postponed","2015-05-04T13:12:03.727","2015-05-04T13:13:51.633","","S2-152138","Rel-13","","","","","","","",null,null,null,"C1-151620"]
["S2-151446","LS from CT WG1: LS on static configuration for ePDG selection","CT WG1","Maurice Pope",648,"LS in","","","CT WG1 has discussed the static configuration aspect of the the ePDG selection procedure specified in 23.402 subclause 4.5.4, which says: 'The UE may select the ePDG by static configuration or dynamically.' No further details are provided about the static configuration in stage 2 specifications. CT WG1 asks SA WG2 to kindly provide additional clarifications about the ePDG selection based on the static configuration, in particular: 1. Is 'static' to be understood as: a. opposite to 'dynamic (selection)' meaning 'not dependent on the current roaming status'; b. implementation-specific; or c. something else? 2. What is the relationship between the static configuration and dynamic selection? 3. Does SA WG2 have specific requirements regarding how this 'static' configuration can be provisioned and modified? CT WG1 looks forward to any further clarifications from SA WG2. Action: CT WG1 asks SA WG2 group to kindly provide clarifications as described in Section 1.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11170,"Postponed","2015-05-04T13:12:03.740","2015-05-04T13:13:51.677","","S2-152139","Rel-13","","","","","","","",null,null,null,"C1-151630","S2-151675"]
["S2-151447","LS from CT WG1: Reply LS on APN Usage in NSWO Rules","CT WG1","Maurice Pope",648,"LS in","","","CT WG1 thanks SA WG2 on their LS on APN usage in NSWO rules. CT WG1 would like to provide the following answers to the questions posed by SA WG2: SA WG2 question (a): clarify the use case that requires the inclusion of APN in the IP filters of 'ISRP for NSWO' and 'IARP for NSWO' rules CT WG1 answer: Including APN in the IP filters of 'ISRP for NSWO' and 'IARP for NSWO' rules can optimize the ANDSF MO and rule configuration. SA WG2 question (b): align TS 24.312 with TS 23.402 and remove the APN from the IP filters of 'ISRP for NSWO' and 'IARP for NSWO CT WG1 answer: CT WG1 decided not to remove the APN from the IP flow description of ISRP for NSWO and IARP for NSWO rules. However to address SA WG2 concern, CT WG1 decided to add a warning note. Action: CT WG1 would like to kindly ask SA WG2 group to take note of the agreed CT WG1 CR.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11300,"Treated","2015-05-04T13:12:03.740","2015-05-04T13:13:51.710","","","Rel-12","","","","","","","",null,null,null,"C1-151631","S2-152082"]
["S2-151448","LS from CT WG1: Reply LS on ProSe direct discovery announcements","CT WG1","Maurice Pope",648,"LS in","","","CT WG1 thanks RAN WG2 for their LS on ProSe direct discovery announcements. CT WG1 would like to confirm that the upper layer should take care of announcing discovery message multiple times while the concerned PAC is valid. The agreed C1-151653 (CR0106R3) is attached.","13","5.1","3GPP Packet Access Maintenance",10430,"Noted","2015-05-04T13:12:03.757","2015-05-04T13:13:51.773","","","Rel-12","","","","","","","",null,null,null,"C1-151654"]
["S2-151449","LS from CT WG4: Reply LS on TR 26.924 Study on improved end-to-end QoS handling","CT WG4","Maurice Pope",648,"LS in","","","CT WG4 would like to thank SA WG4 for their LS (S4-150163) on TR 26.924 Study on improved end-to-end QoS handling and for having the opportunity to comment on TR 26.924 provided by SA WG4 in S4-150162. CT WG4 has reviewed the attached Technical Report as requested and would like to confirm that CT WG4 has not identified any specific impacts from the current version of Technical Report. Since the existing use cases in the current version of the Technical Report focus only on audio and video codec configurations CT WG4 would like to know if SA WG4 plans to include in the Technical Report: 1. instant messaging i.e. MSRP over (TLS/)TCP/IP and MSRP usage for text and file transfer; and 2. realtime text i.e. T.140 over RTP/UDP/IP. CT WG4 would like to request of SA WG4 to be updated with any further progress of the study on improved end-to-end QoS handling and to have the chance to comment to it.","21","6.1.2","Rel-13 PCC/QoS Maintenance",11070,"Noted","2015-05-04T13:12:03.773","2015-05-04T13:13:51.820","","","Rel-13","","","","","","","",null,null,null,"C4-150685"]
["S2-151450","LS from CT WG4: Reply LS on E-RAB(s) failed to modify in E-RAB Modification Confirm","CT WG4","Bruno Landais",17613,"LS in","","","CT WG4 thanks SA WG2 for their LS on E-RAB(s) failed to modify in E-RAB Modification Confirm (S2-150547). CT WG4 agrees with SA WG2 that the MME should be capable to indicate to the Master eNB in the E-RAB MODIFICATION CONFIRM message whether the E-RAB(s) failed to be modified have been maintained or torn down in the EPC. E-RAB(s) can be kept unmodified e.g. when the SGW does not receive or cannot process a Modify Bearer Request(s) or Modify Access Bearers Request, due for instance to an MME overload, an SGW overload, or a transient S11 path failure. In these scenarios, none of the S1-U bearers are modified in the SGW, and thus it makes sense for the MME to maintain the E-RABs and let the MeNB decide whether to keep or delete the bearers. Errors might also happen in rare scenarios, where the SGW is able to receive and process the Modify Bearer Request or Modify Access Bearers Request message(s) but for example the SGW does not find a bearer context being modified by the MME (","13","5.1","3GPP Packet Access Maintenance",10280,"Noted","2015-05-04T13:12:03.773","2015-05-04T13:13:51.850","","","Rel-12","","","","","","","",null,null,null,"C4-150686"]
["S2-151451","LS from CT WG4: LS on UE identity used between ProSe Functions for ProSe Service Authorization","CT WG4","Maurice Pope",648,"LS in","","","It has been agreed in the CT WG4/SA WG2/CT WG1 joint session during CT WG4#67 meeting that both MSISDN and IMSI may be used as UE identity in ProSe procedures between Visited PLMN/Local PLMN ProSe Function and HPLMN ProSe Function. Therefore, CT WG4 has taken this requirement into account while implementing the stage 3 specification for the PC6/PC7 Inter-ProSe Functions interfaces. However, in Stage 2 description in subclause 5.2.2.4 of TS 23.303, IMSI is indicated as the UE identity to be used whereas it is expected that the MSISDN can also be used. It seems that there is then a misalignment between Stage 2 and Stage 3 specifications. Action: CT WG4 kindly asks SA WG2 to confirm that either IMSI or MSISDN can be used as UE identity in service authorisation related procedures over PC6/PC7 and update the SA WG2 specification accordingly, or provide feedback and guidance if SA WG2 does not agree.","13","5.1","3GPP Packet Access Maintenance",10620,"Treated","2015-05-04T13:12:03.787","2015-05-04T13:13:51.880","","","Rel-12","","","","","","","",null,null,null,"C4-150687","S2-152066"]
["S2-151452","LS from SA WG1: Response to Reply LS on Security Framework for Cellular IoT","SA WG1","Chris Pudney",1122,"LS in","","","SA WG1 thanks SA WG3 for their LS in S3-151198. SA WG1 is aware of the reply from GERAN 2 to SA WG3 in GPC150120. SA WG1 is also aware of the SIDs agreed at SA#67 in Shanghai as attached to SA's outgoing LS in SP-150170, and, that the GERAN TR 45.820 has now reached the formal v1.0.0 'for information' status level of >60% completion level (see http://www.3gpp.org/DynaReport/45820.htm). In addition to the questions raised by SA WG3 in the LS, SA WG1understand that SA WG3 would like SA WG1 to provide information about use cases for these ultra-low throughput, extended range and low complexity devices. Hence SA WG1 offer the following observations: a) The 'Internet of Things' is anticipated to be incredibly diverse. b) It is anticipated that some companies build the device chipsets, then other companies install the chipsets in different types of modules, then another set of companies build those modules into different 'wirelessly enabled' products. Hence the same type of chipset","6","4.1","Common issues and Incoming LSs",10080,"Noted","2015-05-04T13:12:03.803","2015-05-04T13:13:51.913","","","Rel-13","","","","","","","",null,null,null,"S1-151528"]
["S2-151453","LS from SA WG4: LS on proposed WID for Media and Quality Aspects of SRVCC Enhancements","SA WG4","Maurice Pope",648,"LS in","","","SA WG4 has been informed that SA WG2 Work Item on SETA (SRVCC Enhancements for Transcoding Avoidance - S2-142912) has been put on hold at SA#66. Because Speech Quality, TrFO, Rate Control and EVS are under SA WG4 ToRs and that SA WG2 SETA work is partly dependent on SA WG4 analysis and vice versa the SETA work is important for enhanced SRVCC for EVS, SA WG4 concluded that it is desirable to support the work on SETA by SA WG4. A proposed new Work Item Description for Media and Quality Aspects of SRVCC Enhancements as a building block of the SETA WID is attached. The intention is to present the proposed new WID for approval at SA#68 (June 2015). Action: SA WG4 kindly asks SA WG2 to take the attached proposed new WID into account.","43","7.2","Review of the Work Plan",16840,"Postponed","2015-05-04T13:12:03.803","2015-05-04T13:13:51.960","","S2-152140","Rel-13","","","","","","","",null,null,null,"S4-150581"]
["S2-151454","LS from SA WG6: Reply to Document C1-151620:  LS on Rel-13 MCPTT work","SA WG6","Alan Soloway",46784,"LS in","","","SA WG6 would like to thank CT WG1 (CT WG1) for contacting SA WG6 for clarification related to Mission Critical Push to Talk (MCPTT). Requested actions to SA WG6: 1. CT WG1 kindly asks SA WG6 to take into account the summary of the CT WG1 discussion above for their Rel-13 work on MCPTT. 2. CT WG1 kindly asks SA WG6 to provide feedback on items a, b and c above to help CT WG1 prepare for their Rel-13 work on MCPTT. In regards to requested action #1, SA WG6 thanks CT WG1 for the information and will take the summary of the CT WG1 discussion into account for the Rel-13 MCPTT work. In regards to requested action #2, please see the individual feedback below for items a, b and c. a. Per CT WG1's Terms of Reference, CT WG1 expects the application and extension of SIP, SDP and XCAP for MCPTT to be under the responsibility of CT WG1. CT WG1 would like to know if SA WG6 has already identified other additional MCPTT protocol aspects b. Which MCPTT architecture aspects will be under the r","24","6.2","Mission Critical Push to Talk over LTE (MCPTT)",11400,"Postponed","2015-05-04T13:12:03.820","2015-05-04T13:13:52.007","","S2-152141","Rel-13","","","","","","","",null,null,null,"S6-150292"]
["S2-151455","MONTE - Resolution of open architectural issues","Cisco Systems France","Maulik Vaidya",44517,"other","","","Provides resolution for open architectural points in MONTE","28","6.6","Monitoring Enhancements (MONTE)",12600,"Available","2015-05-04T14:28:29.657","2015-05-19T05:39:01.910","","","Rel-13","","","","","","","","","","","",""]
["S2-151456","Conclusion for Key issue 1","KDDI Corporation","Takeshi Usui",59388,"pCR","","","This paper discusses the solutions for Flexible Mobile Service Steering that are currently documented in TR 23.718 and proposes a conclusion for Rel-13.","33","6.13","Flexible Mobile Service Steering (FMSS)",15130,"Withdrawn","2015-05-06T07:33:14.707",null,"","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151457","Introduction of monitoring event delete procedure","Cisco, LG Electronics","Maulik Vaidya",44517,"CR","","","Summary of change: The procedures for deletion of previously configured Monitoring Eventis introduced.","28","6.6","Monitoring Enhancements (MONTE)",12750,"Noted","2015-05-07T16:22:08.617","2015-05-19T05:39:01.943","","","Rel-13","23.682","13.1.0","MONTE","0103","","B",null,"","","","",""]
["S2-151458","Introduction of Charging Principles for Monitoring Events feature","Cisco","Maulik Vaidya",44517,"CR","","","Summary of change: Based on agreeements in S2-151455, high-level charging principles to be used for Monitoring Events feature are added.","28","6.6","Monitoring Enhancements (MONTE)",12770,"Revised","2015-05-07T16:24:41.743","2015-05-19T05:39:01.973","","S2-151975","Rel-13","23.682","13.1.0","MONTE","0104","","B",null,"","","","",""]
["S2-151459","LS from GERAN WG2: Reply LS on paging for MTC","GERAN WG2","Maurice Pope",648,"LS in","","","GERAN WG2 thanks SA WG2 for the Response to Reply LS on paging for MTC.  GERAN WG2 has reviewed the LS and in an attempt better clarify GERAN WG2 thinking on the relationship between coverage classes for MTC devices and paging procedures and thereby hopefully move the discussion forward, GERAN WG2 has adopted the following working assumptions related to storage of 'coverage' situation in the CN.  WA 1: The MS shall determine if currently estimated coverage class is different from last reported Coverage Class.  WA 2: The MS should report changes of its coverage class to the CN. The trigger of the reporting, to avoid frequent signaling, is FFS. WA 3: At least the estimated coverage class for downlink will be indicated to the RAN when attempting system access. WA 4: The changes of estimated coverage class for downlink may be indicated to the RAN during data transmission. WA 5: The RAN will include the coverage class information in the uplink data PDU sent to the CN . WA 6: Upon","6","4.1","Common issues and Incoming LSs",10090,"Postponed","2015-05-11T13:34:20.453","2015-05-11T13:50:49.857","","S2-152142","Rel-13","","","","","","","",null,null,null,"GPC150297"]
["S2-151460","LS from RAN WG3: LS on Paging Optimization considering supported frequency bands","RAN WG3","Maurice Pope",648,"LS in","","","RAN WG3 has discussed the solution for reducing radio interface paging load which considers the frequency bands supported by the UE, as described in the LS on Paging Optimization in S2-150698 [1]. RAN WG3 acknowledges that this solution can effectively reduce the radio interface paging load by avoiding paging message in cells using a frequency the UE does not support. The respective information can be provided to the MME within the S1 UE Capability Info Indication message and included by the MME in the S1 Paging message. RAN WG3 has a preference to convey the information in an RRC container over the S1 interface.","6","4.1","Common issues and Incoming LSs",10100,"Postponed","2015-05-11T13:34:20.453","2015-05-11T13:50:49.890","","S2-152143","Rel-13","","","","","","","",null,null,null,"R3-150889"]
["S2-151461","LS from RAN WG3: Response LS on Paging Optimization","RAN WG3","Maurice Pope",648,"LS in","","","RAN WG3 has discussed the LS referenced here-above to provide guidance on how to limit both MME and radio interface paging load. The following recommendations were agreed: RAN WG3 thought beneficial to have the last serving eNB sending 'information on recommended cells and eNBs for paging' that may be stored in MME and may be provided to the eNBs at paging. This 'information on recommended cells and eNBs for paging' could be limited to one cell only if beneficial in some use cases. RAN WG3 recommends this information to be sent by the last serving eNB to the MME at the time of transition to idle (i.e., in the S1AP UE CONTEXT RELEASE COMPLETE message). It is not intended to standardize how the last serving eNB would build this 'information on recommended cells and eNBs for paging'. RAN WG3 is still working to identify more precise recommendations in line with the high level guidelines provided here-above. Action: RAN WG3 kindly ask SA WG2 to take into account the above guidanc","6","4.1","Common issues and Incoming LSs",10110,"Postponed","2015-05-11T13:34:20.467","2015-05-11T13:50:49.920","","S2-152144","Rel-13","","","","","","","",null,null,null,"R3-150892"]
["S2-151462","LS from RAN WG3: Reply LS on E-RAB(s) failed to modify in E-RAB Modification Confirm","RAN WG3","Maurice Pope",648,"LS in","","","RAN WG3 thanks SA WG2 and CT WG4 for their LSs on E-RAB(s) failed to modify in E-RAB Modification Confirm. RAN WG3 has taken the information provided by CT WG4 in C4-150686 into account and aligned stage 3 accordingly: - E-RAB(s) the EPC failed to modify but may be kept unmodified can be already indicated by the MME. The MeNB finally decides whether to keep or release those E-RAB(s). - E-RAB(s) for which corresponding bearer contexts have been deleted in the MME requires new information to be added to the E-RAB MODIFICATION CONFIRM message. Upon receiving this new information the MeNB releases the E-UTRA(N)resources for those E-RABs. Action: RAN WG3 kindly asks CT WG4 and SA WG2 to take the above information into account and align their specification if necessary.","13","5.1","3GPP Packet Access Maintenance",10290,"Noted","2015-05-11T13:34:20.467","2015-05-11T13:50:49.950","","","Rel-12","","","","","","","",null,null,null,"R3-150896"]
["S2-151463","LS from RAN WG3: Reply LS on SC-PTM transmission","RAN WG3","Maurice Pope",648,"LS in","","","RAN WG3 thanks RAN WG2 for their LS R2-150709 on SC-PTM transmission. RAN WG3 discussed the architecture and high level procedure for Single-cell PTM transmission in LTE and agreed that the MCE makes the decision on whether to use SC-PTM or MBSFN. In case of distributed MCE architecture, ensuring the same decision in all MCEs (located in eNB), with regards to existing MBSFN areas, requires more coordination effort (e.g. via OAM). RAN WG3 currently assumes that the CN will provide information to the MCE to assist the MCE's decision. In case the MCE decides to use SC-PTM, the MCE will then provide information to the eNB including the list of cell identities and QoS information of the service, so that the eNB uses SC-PTM for the related MBMS service in the relevant cell(s). The agreed Text Proposal to TR36.890 is attached. Action: RAN WG3 asks RAN WG2 and SA WG2 to take the above feedback into account for their study of SC-PTM transmission.","34","6.14","MBMS Enhancements (MBMS_enh)",15150,"Noted","2015-05-11T13:34:20.483","2015-05-11T13:50:49.997","","","Rel-13","","","","","","","",null,null,null,"R3-150917"]
["S2-151464","LS from SA WG3: LS on the risk of IMSI exposure at the SCEF","SA WG3","Wei Lu",43558,"LS in","","","In the context of MTCe security discussion in SA WG3, it is recognized that the SCEF could be possibly controlled by a 3GPP operator, or by a partner operator, or by a 3rd party. SA WG3 discussed on #79 meeting the risk of 3GPP private subscriber identity (e.g. IMSI/IMPI) exposure at the SCEF, and came to the conclusion that IMSI/IMPI shall not be sent to the SCEF when controlled by a 3rd party which is outside the 3GPP operator's domain. However, it is observed that in some of the SA WG2 solutions in the current TR23.769 (v.1.1.0) and TR23.789 (v.1.1.0), the SCEF is allowed to get hold of the IMSI/IMPI. It is understood by SA WG3 that, the MTC-IWF is required to receive and store the subscriber's internal ID (e.g. IMSI) from the HSS for addressing MTC features (e.g. device triggering, group based addressing and identifier, monitoring or reporting MONTE events) in Rel 12. With the architecture enhanced for service capability exposure in Rel-13, the Rel-12 MTC-IWF is decompose","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12060,"Treated","2015-05-11T13:34:20.483","2015-05-11T13:50:50.030","","","Rel-13","","","","","","","",null,null,null,"S3-151477","S2-152123"]
["S2-151465","LS from SA WG3: Reply LS on C3-150424 LS on Enable MB2 authorization","SA WG3","Maurice Pope",648,"LS in","","","SA WG3 would like to thank CT WG3 on their LS on Enable MB2 authorization (S3-151218/C3-150424). SA WG3 would like to provide the following answers to the questions of CT WG3. [...]","13","5.1","3GPP Packet Access Maintenance",10700,"Noted","2015-05-11T13:34:20.500","2015-05-11T13:50:50.060","","","Rel-12","","","","","","","",null,null,null,"S3-151480"]
["S2-151466","LS from SA WG3: Reply LS on end-to-end WebRTC-IMS security","SA WG3","Maurice Pope",648,"LS in","","","SA WG3 would like to thank SA WG1 for their LS on end-to-end WebRTC-IMS security, clarifying that SA WG1 considers both, hop-by-hop encryption as well as strict end-to-end encryption, as possible options for WebRTC e2e security. SA WG3 discussed, that when using hop-by-hop encryption, the security solution for end-to-access-edge (e2ae) security described in TS 33.328 applies. According to the SA WG1 reply LS, strict e2e encryption can only be used when LI requirements do not apply. It is still unclear in SA WG3 which aspects of e2e security solutions for such cases are in the scope of 3GPP. The estimated amount of work on this issue will not allow SA WG3 to be able to complete e2e security where LI requirements do not apply for WebRTC in Release 13.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13250,"Noted","2015-05-11T13:34:20.517","2015-05-11T13:50:50.093","","","Rel-13","","","","","","","",null,null,null,"S3-151499"]
["S2-151467","LS from SA WG3: Reply LS on public safety discovery","SA WG3","Adrian Escott",24089,"LS in","","","SA WG3 thanks SA WG2 for their LS (S2-150691/S3-151226) on public safety discovery. SA WG3 have started their study on security for the cases of group member discovery etc., but have not yet come to any final conclusions on the subject.  In order to help make progress on their work, SA WG3 would like feedback on the following questions SA WG3 has noticed that in the LS (S3-151226) and SA WG2 TR 23.713 the term Group Member discovery is used  Q1: SA WG3 would like to ask SA WG1 whether there is a requirement for Group Member Discovery?  If so, what are the use cases and requirements for Group Member discovery.  In particular whether, for UEs to discover other UEs they only need to be members of its group.  (Note: as in ProSe one-to-many protection, this provides assurance that a member of the group is present, but not a specific individual).  SA WG3 could not find any SA WG1 requirements in TS 22.278 corresponding to Group Member discovery.  Q2: SA WG3 would like to ask SA WG2","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13760,"Treated","2015-05-11T13:34:20.517","2015-05-11T13:50:50.137","","","Rel-13","","","","","","","",null,null,null,"S3-151524","S2-151813"]
["S2-151468","LS from ETSI ISG Chairman: Liaison about ETSI ISG IP6 creation and interaction with other groups","ETSI ISG Chairman","Maurice Pope",648,"LS in","","","Dear Madam, Dear Sir, We are pleased to inform you that ETSI has successfully held the first meeting of their newly created Industry Specification Group on IPv6 Integration on 22-23 April, 2015. The ETSI 'IPv6 integration' Industry Specification Group (IP6 ISG) is a working group to focus on IPv6-based best practices, deployment guidelines and success showcases identifying thereby what and where consensus and harmonization could be reached. We invite all interested parties from your organization or others to join in. Participation in the ISG IP6 is subject to signature of an ISG IP6 Agreement you can find at https://portal.etsi.org/tb.aspx?tbid=827&SubTB=827. Explanation about those agreements is also available from the same location. We have started work on the following items: - IPv6 Deployment in the Enterprise - IPv6 in Telecom /ISPs - IPv6 in Safety & Emergency Sector - IPv6 For Academia & Education - IPv6 For Governments - Generic migration steps from IPv4 to IPv6 - IPv","6","4.1","Common issues and Incoming LSs",10070,"Noted","2015-05-11T14:33:36.183","2015-05-19T05:35:42.277","","","","","","","","","","",null,null,null,"IP6(15)001031"]
["S2-151469","Clarification of Key Issue 1 on ePDG Selection for Emergency Services","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution includes clarification to key issue 1","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15880,"Revised","2015-05-11T21:35:44.487","2015-05-18T19:15:58.800","","S2-151821","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151470","Clarification of Key Issue 2 on Providing Priority to Emergency Services","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution includes clarification to key issue 2","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15910,"Approved","2015-05-11T21:35:44.500","2015-05-18T19:15:58.833","","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151471","Support for Distinguished Location Information on WLAN","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution discusses the Nature of the Access Network Information to be reported in case of an unmanaged WAN access as well as their distinctiveness.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15930,"Noted","2015-05-11T21:35:44.500","2015-05-18T19:15:58.863","","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151472","Base Solution for Key issue 3: Handling of UE multiple provided Location Information","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution proposes solution to the key issue # 6 to distinguish multiple UE provided location and access information","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15940,"Revised","2015-05-11T21:35:44.517","2015-05-18T19:15:58.893","","S2-151822","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151473","Enhanced MSC Server announcement during Session Transfer","Ericsson","Shabnam Sultana",21207,"CR","","","Summary of change: Remove the list to avoid missing cases","16","5.4","IMS-Related Maintenance",10920,"Revised","2015-05-11T21:35:44.517","2015-05-18T19:15:58.910","","S2-151780","Rel-12","23.237","12.8.0","vSRVCC, TEI12","0483","","F",null,"","","","",""]
["S2-151474","On Public Safety discovery message transport","Qualcomm Incorporated, ZTE, U.S. Department of Commerce, Alcatel Lucent","Haris Zisimopoulos",41602,"pCR","","","This paper calculates the estimated discovery message for public safety discovery and proposes to use PC5-D discovery for ProSe UE-Network Relay and Group Member Discovery.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13710,"Revised","2015-05-12T09:22:12.790","2015-05-19T12:54:11.027","","S2-151773","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151475","Group member discovery","Qualcomm Incorporated","Haris Zisimopoulos",41602,"other","","","This paper discusses LS S3-151542 and the implications for discovery transport.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13850,"Available","2015-05-12T09:25:26.857","2015-05-19T12:54:11.060","","","Rel-13","","","","","","","","","","","",""]
["S2-151476","TMGI and ECGI advertisement","Qualcomm Incorporated, Alcatel Lucent","Haris Zisimopoulos",41602,"pCR","","","This paper proposes to use PC5-D discovery for ProSe UE-Network Relay TMGI and ECGI advertisement.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13910,"Revised","2015-05-12T09:33:04.313","2015-05-19T12:54:11.077","","S2-151794","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151477","MBMS_Enh Solution Evaluation and Conclusion","Alcatel-Lucent","Mike Dolan",1692,"pCR","","","This contribution provides an evaluation of Solutions 1 and 2 and a conclusion for TR 23.741 (MBMS_Enh).","34","6.14","MBMS Enhancements (MBMS_enh)",15270,"Revised","2015-05-12T19:33:27.327","2015-05-12T19:37:36.007","","S2-151917","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151478","[DRAFT] LS on Flow ID supplied by GCS AS","SA WG2","Mike Dolan",1692,"LS out","","","SA WG2 thanks CT WG3 for your LS on Flow ID supplied by GCS AS (S2-150712/C3-150446). SA WG2 reaffirms that there is an agreement with CT WG3 that the BM-SC shall be responsible for allocation of the Flow ID and that there is no predefined meaning. Therefore, SA WG2 have agreed CRxxxx to TS 23.468 for Rel-12 to allow only the BM-SC to allocate the Flow ID.","13","5.1","3GPP Packet Access Maintenance",10790,"Revised","2015-05-12T19:45:55.583","2015-05-12T19:47:40.400","","S2-152069","Rel-12","","","","","","","","S2-151437","CT WG3"]
["S2-151479","Correct FlowID per agreement with CT WG3","Alcatel-Lucent, Nokia Networks, Samsung","Mike Dolan",1692,"CR","","","Summary of change: The FlowID is allocated in all cases by the BM-SC in the Activate MBMS Bearer procedure.","13","5.1","3GPP Packet Access Maintenance",10720,"Revised","2015-05-12T19:51:33.013","2015-05-12T20:00:06.913","","S2-152067","Rel-12","23.468","12.4.0","GCSE_LTE","0058","","F",null,"","","","",""]
["S2-151480","Correct FlowID per agreement with CT WG3","Alcatel-Lucent, Nokia Networks, Samsung","Mike Dolan",1692,"CR","","","Rel-13 mirror CR: Summary of change: The FlowID is allocated in all cases by the BM-SC in the Activate MBMS Bearer procedure.","13","5.1","3GPP Packet Access Maintenance",10740,"Revised","2015-05-12T19:56:26.780","2015-05-12T20:00:06.867","","S2-152068","Rel-13","23.468","13.0.0","GCSE_LTE","0059","","A",null,"","","","",""]
["S2-151481","[DRAFT] LS on the risk of IMSI exposure at the SCEF","Alcatel-Lucent","Laurent Thiebaut",11066,"LS out","","","SA WG2 thanks SA WG3 for your LS on the risk of IMSI exposure at the SCEF. SA WG2 notes that TS 23.682 v13.0 clause 4.2 says:The trust domain (see figure 4.2-2) cover entities that are protected by adequate network domain security. The entities and interfaces within the trust domain may all be within one operator's control, or some may be controlled by a trusted business partner which has a trust relationship with the operator e.g. another operator or a 3rd party. When not under the control of the PLMN operator, it is up to the PLMN operator to ensure that access to the PLMN operator's network from the SCEF is deployed in a manner consistent with security principles of the 3GPP network as outlined by SA WG3 security specifications.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12070,"Revised","2015-05-12T20:08:36.897","2015-05-12T20:13:46.167","","S2-151914","Rel-13","","","","","","","","S2-151464","SA WG3"]
["S2-151482","Service access number translation by an application","Orange","Antoine Mouquet",38438,"CR","","","Summary of change: An new section 4.2.1.4 is added to describe how and why an application may provide in the SIP signalling the information that it has translated a service access number into a routeable number towards an end user.","40","6.20.4","TEI13 Category B/C for IMS, IMS-Related, Emergency, Other",16510,"Noted","2015-05-13T12:46:40.117","2015-05-19T14:21:41.500","","","Rel-13","23.228","13.2.0","TEI13","1130","","B",null,"","","","",""]
["S2-151483","Support for Monitoring Events","Intel, Cisco","Maulik Vaidya",44517,"CR","","","Summary of change: High level description for Monitoring Events feature. Support for Gn/Gp SGSN is clarified.","28","6.6","Monitoring Enhancements (MONTE)",12690,"Revised","2015-05-13T14:56:23.677","2015-05-19T05:39:02.007","S2-151274","S2-151903","Rel-13","23.060","13.2.0","MONTE","1961","3","B",null,"","","","",""]
["S2-151484","FMSS solution evaluation criteria","Cisco, Allot Communications, Alcatel-Lucent, Alcatel-Lucent Shanghai-Bell, Huawei, Hisilicon, Comverse, Sprint, Openet Telecom, T-Mobile USA, Sandvine Incorporated, Softbank Mobile","Nirav Salot",56645,"pCR","","","This paper proposes criteria for evaluating various FMSS solutions on objective basis.","33","6.13","Flexible Mobile Service Steering (FMSS)",14950,"Available","2015-05-14T10:14:23.193","2015-05-19T10:39:34.437","","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151485","Evaluation of solutions for key issue#1 and key issue#2","Cisco, Allot Communications, Alcatel-Lucent, Alcatel-Lucent Shanghai-Bell, Huawei, Hisilicon, Comverse, Sprint, Openet Telecom, T-Mobile USA, Sandvine Incorporated, Softbank Mobile","Nirav Salot",56645,"pCR","","","This paper proposes evaluation of solutions for key issue#1 and key issue#2.","33","6.13","Flexible Mobile Service Steering (FMSS)",14970,"Available","2015-05-14T10:16:18.617","2015-05-19T10:39:34.453","","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151486","Aspects of metadata transfer and application reporting support for TDF/PCEF","Allot Communications, Cisco, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Comverse, SPRINT, Openet Telecom, Sandvine Incorporated","Alla Goldner",42718,"pCR","","","This contribution addresses aspects of metadata transfer and of application reporting for traffic steering policy generation for the Sd/Gx based solutions.","33","6.13","Flexible Mobile Service Steering (FMSS)",14750,"Revised","2015-05-14T12:33:02.600","2015-05-19T10:54:58.303","","S2-151898","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151487","Aspects of application identification for FMSS solution","Allot Communications, Cisco, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Huawei, HiSilicon, Comverse, Openet Telecom, Sandvine Incorporated","Alla Goldner",42718,"pCR","","","This contribution analyses requirements related to application identification and adds points to reflect application identification handling.","33","6.13","Flexible Mobile Service Steering (FMSS)",14780,"Revised","2015-05-14T12:37:11.077","2015-05-19T10:55:13.963","","S2-151899","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151488","Correction of CSFB references for CS domain priority schemes","Applied Communication Sciences, OEC","Donald Lukacs",56642,"CR","","","Summary of change: This CR corrects CSFB specification references to CS domain priority schemes, as contained in TS 23.272 for Release 11. References should be to TIA-917 and TR 22.952, consistent with corresponding references provided in Clause 4.7.","13","5.1","3GPP Packet Access Maintenance",10340,"Agreed","2015-05-14T17:24:26.840","2015-05-15T18:42:42","","","Rel-11","23.272","11.9.0","eMPS, TEI11","0945","","F","SP-150224","","","","",""]
["S2-151489","Correction of CSFB references for CS domain priority schemes","Applied Communication Sciences, OEC","Donald Lukacs",56642,"CR","","","Rel-12 mirror CR: Summary of change: This CR corrects CSFB specification references to CS domain priority schemes, as contained in TS 23.272 for Release 12. References should be to TIA-917 and TR 22.952, consistent with corresponding references provided in Clause 4.7.","13","5.1","3GPP Packet Access Maintenance",10350,"Agreed","2015-05-14T17:31:49.700","2015-05-15T18:42:42.030","","","Rel-12","23.272","12.5.0","eMPS, TEI11","0946","","A","SP-150224","","","","",""]
["S2-151490","Evaluation of FMSS solutions","Ericsson, Orange, AT&T, Nokia, NEC","Shabnam Sultana",21207,"pCR","","","This paper discusses the solutions for Flexible Mobile Service Steering that are currently documented in TR 23.718 and proposes a conclusion for Rel-13.","33","6.13","Flexible Mobile Service Steering (FMSS)",14980,"Available","2015-05-14T19:55:10.287","2015-05-19T12:08:05.283","","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151491","Monitoring via PCRF","Ericsson","Shabnam Sultana",21207,"CR","","","Monitoring events via PCRF as discussed in the study phase","28","6.6","Monitoring Enhancements (MONTE)",12890,"Withdrawn","2015-05-14T19:55:10.287",null,"S2-151409","","Rel-13","23.682","13.1.0","MONTE","0105","","B",null,"","","","",""]
["S2-151492","Clarify APN configuration for connectivity to ProSe Function","Ericsson","Shabnam Sultana",21207,"CR","","","Summary of change: Update the Note to reflect that and APN maybe configured to indicate signalling connectivity towards ProSe Function in the HPLMN.","13","5.1","3GPP Packet Access Maintenance",10650,"Agreed","2015-05-14T19:55:10.363","2015-05-18T19:15:58.940","","","Rel-12","23.303","12.4.0","ProSe","0163","","F","SP-150226","","","","",""]
["S2-151493","Coversheet sending TR 23.709 for approval","Ericsson","Shabnam Sultana",21207,"WI status report","","","Coversheet sending TR 23.709 for approval","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14640,"Revised","2015-05-14T19:55:10.443","2015-05-19T12:08:49.697","","S2-151982","Rel-13","","","","","","","","","","","",""]
["S2-151494","WID for HLCOM normative work","Ericsson","Shabnam Sultana",21207,"WID","","","WID for HLCOM normative work","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16690,"Revised","2015-05-14T19:55:10.457","2015-05-19T12:12:59.520","","S2-151874","Rel-13","","","","","","","","","","","",""]
["S2-151495","Exception for HLCOM normative work","Ericsson","Shabnam Sultana",21207,"WI status report","","","Exception for HLCOM normative work (if it does not get finalized in SA WG2#109)","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14670,"Revised","2015-05-14T19:55:10.457","2015-05-19T12:12:59.550","","S2-152052","Rel-13","","","","","","","","","","","",""]
["S2-151496","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent","Shabnam Sultana",21207,"CR","","","Summary of change: Introduced description of the functions for High latency communication.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14440,"Revised","2015-05-14T19:55:10.473","2015-05-19T12:58:11.473","","S2-151905","Rel-13","23.682","13.1.0","TEI13","0106","","B",null,"","","","",""]
["S2-151497","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent","Shabnam Sultana",21207,"CR","","","Summary of change: Changes according to conclusions in the FS_HLCOM study TR 23.709.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14480,"Revised","2015-05-14T19:55:10.567","2015-05-19T12:58:11.507","","S2-151906","Rel-13","23.401","13.2.0","TEI13","2862","","B",null,"","","","",""]
["S2-151498","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent","Shabnam Sultana",21207,"CR","","","Summary of change: Changes according to conclusions in the FS_HLCOM study TR 23.709.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14520,"Revised","2015-05-14T19:55:10.660","2015-05-19T13:38:56.593","","S2-151979","Rel-13","23.060","13.2.0","TEI13","1965","","B",null,"","","","",""]
["S2-151499","Introduce the Dedicated Core Network (DECOR) feature","Ericsson, AT&T","Shabnam Sultana",21207,"CR","","","Adding minor and editorial updates to agreed CR in S2#108. Changes marked in yellow colour.","25","6.3","Dedicated Core Networks (DECOR)",11510,"Withdrawn","2015-05-14T19:55:10.753",null,"","","Rel-13","23.401","13.2.0","DECOR","2863","","B",null,"","","","",""]
["S2-151500","Adding support for load re-balancing within DCN","Ericsson, TeliaSonera, AT&T","Shabnam Sultana",21207,"CR","","","Summary of change: Describes load re-balancing using the NAS Message Redirection procedure within a DCN for E-UTRAN.","25","6.3","Dedicated Core Networks (DECOR)",11530,"Revised","2015-05-14T19:55:10.847","2015-05-19T12:47:40.383","","S2-151789","Rel-13","23.401","13.2.0","DECOR","2864","","B",null,"","","","",""]
["S2-151501","Adding support for load re-balancing within a DCN","Ericsson, TeliaSonera, AT&T","Shabnam Sultana",21207,"CR","","","Summary of change: Describes load re-balancing using the NAS Message Redirection procedure within a DCN for UTRAN and GERAN.","25","6.3","Dedicated Core Networks (DECOR)",11570,"Merged","2015-05-14T19:55:10.940","2015-05-19T12:47:40.417","","","Rel-13","23.060","13.2.0","DECOR","1966","","B",null,"","","","",""]
["S2-151502","Enhancing roaming architecture for Service Exposure","Ericsson","Shabnam Sultana",21207,"other","","","Proposing to address roaming aspects with SE architecture (should be on agenda items 6.5 & 6.6 but could not allocate two agenda items in the tool)","28","6.6","Monitoring Enhancements (MONTE)",12620,"Available","2015-05-14T19:55:11.020","2015-05-19T12:18:06.593","","","Rel-13","","","","","","","","","","","",""]
["S2-151503","Enhancing roaming architecture for Service Exposure","Ericsson","Shabnam Sultana",21207,"CR","","","Summary of change: Introduce a lightweight proxy to aggregate communication with external parties.","28","6.6","Monitoring Enhancements (MONTE)",12630,"Revised","2015-05-14T19:55:11.033","2015-05-19T12:18:06.627","","S2-151946","Rel-13","23.682","13.1.0","AESE, MONTE","0107","","B",null,"","","","",""]
["S2-151504","Updates to St based architecture solution","Ericsson, AT&T","Shabnam Sultana",21207,"pCR","","","Proposes updates to the solution based on St interface in order to resolve open issues and to clarify the relation with IETF/ONF architectures.","33","6.13","Flexible Mobile Service Steering (FMSS)",14800,"Revised","2015-05-14T19:55:11.113","2015-05-19T12:18:06.673","","S2-151900","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151505","NBIFOM call flows over WLAN","Ericsson, ZTE, Alcatel-Lucent, Alcatel-Lucent Shanghai-Bell, Huawei, HiSilicon","Shabnam Sultana",21207,"pCR","","","Proposes normative call flows over WLAN based on the NBIFOM TR conclusions","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11800,"Revised","2015-05-14T19:55:11.113","2015-05-19T13:13:14.057","","S2-151845","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151506","User CSG Information in TAU/RAU with SGW change procedure","Ericsson, Verizon UK Ltd","Shabnam Sultana",21207,"CR","","","Summary of change: Notes 5 in clause 5.3.3.1 and Note 4 in clause 5.3.3.6 are removed which changes the condition when CSG inormation is included in the Create Session Request. The change wil not give any additional signalling over S4/S11 or S5/S8.","20","6.1.1","Rel-13 3GPP Pkt Access Maintenence",11060,"Agreed","2015-05-14T19:55:11.127","2015-05-18T19:15:58.973","","","Rel-13","23.401","13.2.0","TEI13","2865","","F","SP-150239","","","","",""]
["S2-151507","Address metadata report related Editor's notes for St based solution","China Telecom","Jinyan Li",46923,"pCR","","","This contribution intends to resolve the metadata reporting related editor's note for the St based solutions.","33","6.13","Flexible Mobile Service Steering (FMSS)",14830,"Revised","2015-05-15T09:38:22.913","2015-05-19T05:32:37.243","","S2-151935","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151508","Group specific NAS Level congestion control for multiple APNs","NTT DOCOMO","SRISAKUL THAKOLSRI",42550,"CR","","","Summary of change: It is proposed that the MME sends a NAS ESM message type that allows the UE belonging to a particular group to be blocked to stop sending a NAS ESM requests for all APNs.","29","6.7","Group based Enhancements (GROUPE)",12900,"Revised","2015-05-15T21:48:23.343","2015-05-19T11:32:18.620","","S2-151881","Rel-13","23.401","13.2.0","GROUPE","2866","","B",null,"","","","",""]
["S2-151509","Group specific NAS level congestion control for multiple APNs","NTT DOCOMO","SRISAKUL THAKOLSRI",42550,"CR","","","Summary of change: It is proposed that the SGSN sends a NAS SM message type that allows the MS belonging to a particular group to be blocked to stop sending a NAS SM requests for all APNs.","29","6.7","Group based Enhancements (GROUPE)",12940,"Revised","2015-05-15T21:52:11.450","2015-05-19T11:30:14.863","","S2-151882","Rel-13","23.060","13.2.0","GROUPE","1967","","B",null,"","","","",""]
["S2-151510","Monitoring Feature Description","Intel, Huawei, Alcatel-Lucent, Cisco, Ericsson, LG Electronics","Puneet Jain",36283,"CR","","","Summary of change: High level description for monitoring function and monitoring via HSS, SGSN/MME and PCRF is specified.","28","6.6","Monitoring Enhancements (MONTE)",12680,"Agreed","2015-05-15T21:53:02.803","2015-05-19T11:24:13.813","S2-151408","","Rel-13","23.682","13.1.0","MONTE","0100","4","B","SP-150236","","","","",""]
["S2-151511","Restricted ProSe Direct Discovery Model B procedures","InterDigital, Qualcomm Incorporated, Telecom Italia","Mahmoud Watfa",41881,"CR","","","Summary of change: Adding the introductions and procedure details for Restricted ProSe Direct Discovery Model B procedures.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14310,"Revised","2015-05-16T02:35:21.200","2015-05-16T02:49:12.237","","S2-151802","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0164","","B",null,"","","","",""]
["S2-151512","Authorization for broadcasting and use of location information over PC5 for restricted discovery","InterDigital","Mahmoud Watfa",41881,"pCR","","","This document ensures a user is authorized to include location information in PC5 discovery message when announcing, and a user is authorized to use location information in PC5 discovery message when monitoring - both for restricted direct discovery.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14120,"Revised","2015-05-16T02:39:17.287","2015-05-16T02:49:12.297","","S2-151799","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151513","Cover Sheet for TR 23.708 for Approval at TSG SA","Intel","Puneet Jain",36283,"TS or TR","","","Proposes a cover page for submitting TR 23.708 v1.2.0 to SA#68 plenary for Approval","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12380,"Revised","2015-05-16T23:22:01.790","2015-05-19T11:24:13.780","","S2-151944","Rel-13","23.708","1.1.0","AESE","","","","","","","","",""]
["S2-151514","[DRAFT] LS on 3GPP Rel-13 MTC features for service capability exposure","Intel","Puneet Jain",36283,"LS out","","","LS to GSMA, OMA, oneM2M on Rel-13 MTC feature","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12410,"Revised","2015-05-16T23:29:36.323","2015-05-19T11:24:13.750","","S2-151945","Rel-13","","","","","","","",null,"GSMA, OMA, oneM2M"]
["S2-151515","Correction in section 8.1.2.3.3","Telecom Italia","Mario Madella",23765,"pCR","","","Correction of a wrong caption.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14230,"Available","2015-05-17T15:34:12.790","2015-05-17T15:39:56.710","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151516","Key Issues 2 solution","BlackBerry UK Ltd","Adrian Buckley",26735,"pCR","","","Sending an indication from the UE to the network so network knows its an emergency request.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15920,"Available","2015-05-17T19:09:51.123","2015-05-19T17:15:48.410","","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151517","Key issue 1 solution","BlackBerry UK Ltd","Adrian Buckley",26735,"pCR","","","TS 23.401 defines 2 ways that an ePDG can be selected. One is via static configuration, the other is a defined dynamic algorithm. TR 23.771 V0.1.0 has already identified that there is a need to select the correct ePDG for emergency calls.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15900,"Available","2015-05-17T19:19:53.967","2015-05-19T17:15:48.380","","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151518","WID on Support of Emergency services over WLAN - phase 1","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, AT&T, Nokia Networks, Sprint","Laurent Thiebaut",11066,"WID","","","new WID on Support of Emergency services over WLAN - phase 1","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16710,"Revised","2015-05-17T20:06:11.020","2015-05-19T11:59:47.513","","S2-151875","Rel-13","","","","","","","","","","","",""]
["S2-151519","Text for TS section 1-4","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Broadcom Corporation, ZTE, Huawei, HiSilicon","Laurent Thiebaut",11066,"pCR","","","This contribution proposes text for section 1-4 of the future TS on NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11720,"Revised","2015-05-17T20:10:08.857","2015-05-19T11:59:47.530","","S2-151838","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151520","Text for TS section 5","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Broadcom Corporation, ZTE, Huawei, HiSilicon","Laurent Thiebaut",11066,"pCR","","","This contribution proposes text for section 5 of the future TS on NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11750,"Revised","2015-05-17T20:12:47.837","2015-05-19T11:59:47.560","","S2-151839","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151521","Overall procedure to set-up a PDN connection for emergency services","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","description of how the overall process to set up an Emergency session over WLAN would work in phase 1","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16160,"Revised","2015-05-17T20:54:09.400","2015-05-19T11:59:47.590","","S2-151840","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151522","Avoiding invocation of SRVCC for webRTC flows","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"CR","","","Summary of change: When the operator wants to avoid SRVCC to apply to WebRTC related sessions, the operator should configure PCRF policies so that not to use QCI I for WebRTC traffic","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13310,"Revised","2015-05-17T20:54:09.400","2015-05-19T11:59:47.623","","S2-151850","Rel-13","23.228","13.2.0","eWebRTCi","1131","","C",null,"","","","",""]
["S2-151523","Concluding on the support of Inter UE transfer for WebRTC based UE","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","Proposes a solution and a conclusion on the support of Inter UE transfer for WebRTC based UE","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13140,"Revised","2015-05-17T20:54:09.480","2015-05-19T13:11:28.383","","S2-151831","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151524","Presentation of 23.706 (eWebRTCi) to SA","Alcatel-Lucent","Laurent Thiebaut",11066,"TS or TR","","","Presentation of 23.706 (eWebRTCi) to SA","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13390,"Revised","2015-05-17T20:54:09.493","2015-05-19T13:24:27.647","","S2-151854","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151525","Presentation of 23.771 (FS_SEW) to SA","Alcatel-Lucent","Laurent Thiebaut",11066,"TS or TR","","","Presentation of 23.771 (FS_SEW) to SA","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16250,"Revised","2015-05-17T20:54:09.540","2015-05-19T12:05:17.490","","S2-151842","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151526","Conclusion for connected mode e-DRX","LG Electronics","Jinsook Ryu",39022,"pCR","","","This paper proposes the connected mode DRX cycle should be considered to be extended up to 10.24 seconds, instead of introduction of a new eDRX cycle/state with unnecessary complexity in RAN/CN.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15570,"Merged","2015-05-18T00:35:43.653","2015-05-18T00:58:51.517","","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151527","Solve the editor's note of providing the emergency request indication","CATT","Yunjing Hou",46707,"pCR","","","This P-CR is proposed to solve the editor's note of providing the emergency request indication in section 4.1 in TR 23.771.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16200,"Noted","2015-05-18T01:08:25.473","2015-05-18T04:13:46.617","","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151528","Solve the editor's note about the UE configuration","CATT","Yunjing Hou",46707,"pCR","","","This P-CR is proposed to solve the editor's note about the UE configuration.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16210,"Available","2015-05-18T01:10:10.460","2015-05-18T04:13:46.647","","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151529","Evaluation criteria of FMSS Solution","China Mobile, CATR","Tao Sun",54129,"pCR","","","Add the evaluation criteria for the overall evaluation in section 7.1 of TR 23.718","33","6.13","Flexible Mobile Service Steering (FMSS)",14960,"Available","2015-05-18T02:11:30.403","2015-05-19T10:21:55.480","","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151530","Conclusion of FMSS","China Mobile, Broadcom, CATR, China Telecom, China Unicom","Tao Sun",54129,"pCR","","","This paper propose a conclusion for FMSS in R-13","33","6.13","Flexible Mobile Service Steering (FMSS)",14990,"Revised","2015-05-18T02:13:44.953","2015-05-19T13:52:56.040","","S2-151933","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151531","Using RAN Rule in NBIFOM","Huawei, HiSilicon, ZTE","Runze Zhou",60945,"pCR","","","This contribution discusses using RAN Rule in NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11940,"Revised","2015-05-18T02:15:28.380","2015-05-19T11:31:02.413","","S2-151848","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151532","Downlink Routing Rule generation in UE-initiated mode","Huawei, HiSilicon, ZTE","Runze Zhou",60945,"pCR","","","This contribution discusses options to generate downlink Routing Rule (RR) in UE-initiated mode when ANDSF policy is used for traffic steering.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11980,"Merged","2015-05-18T02:15:28.380","2015-05-19T11:31:02.443","","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151533","Clarification of ePDG selection function","Huawei, HiSilicon","Runze Zhou",60945,"CR","","","Summary of change: Clarify that the home operator may use the static ePDG selection to make UE select the Home ePDG as the preferred option.  Clarify that the home operator may configure a PLMN list to control whether static ePDG selection or dynamic ePDG selection is used.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11180,"Available","2015-05-18T02:15:28.397","2015-05-19T11:31:02.473","","","Rel-13","23.402","13.1.0","TEI13","1361","","F",null,"","","","",""]
["S2-151534","[draft] Reply LS on static configuration for ePDG selection","Huawei, HiSilicon","Huan Li",43311,"LS out","","","Reply LS on static configuration for ePDG selection from CT WG1.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11190,"Available","2015-05-18T02:15:28.457","2015-05-19T11:31:02.490","","","Rel-13","","","","","","","","S2-151446","CT WG1"]
["S2-151535","Reference version of FMSS TR 23.718 v0.3.0","China Mobile","Tao Sun",54129,"pCR","","","Provide a Reference version of TR 23.718","33","6.13","Flexible Mobile Service Steering (FMSS)",14740,"Noted","2015-05-18T02:18:58.310","2015-05-19T10:21:55.463","","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151536","Solution evaluation for Idle Mode eDRX Issue 2","LG Electronics","Jinsook Ryu",39022,"pCR","","","In this paper, it is proposed to adopt CN based solution for paging strategy on idle mode Issue 2. Therefore it is provided some explanations to resolve the raised concerns against CN based approach during second Conference Call. Further, some evaluation has been added for RAN based solution 'Paging Strategy Left to MME/SGSN Implementation'.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15430,"Available","2015-05-18T05:40:10.277","2015-05-19T07:51:20.023","","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151537","Discussion on Paging for MTC & Paging Optimization","LG Electronics","Jinsook Ryu",39022,"other","","","This paper summarized the ongoing discussion on Paging for MTC and Paging optimization issue and analyzed the reply LS from RAN WG1,2,3 and GERAN also. Then way forward is also provided based on the analysis.","39","6.20.1","TEI13 Category B/C for 3GPP Packet Access",16450,"Available","2015-05-18T05:44:55.957","2015-05-19T07:51:49.150","","","Rel-13","","","","","","","","","","","",""]
["S2-151538","HLcom solution reusing Monitoring Event 'UE Reachability' realization","LG Electronics","Jinsook Ryu",39022,"CR","","","Summary of change: The procedure for 'Using Monitoring Event - UE Reachability' in TR 23.709 is proposed to be reflected to this spec.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14560,"Revised","2015-05-18T05:55:45.340","2015-05-19T08:04:45.977","","S2-151980","Rel-13","23.682","13.1.0","HLcom","0108","","B",null,"","","","",""]
["S2-151539","Introduce the Dedicated Core Network (DECOR) feature","NTT DOCOMO, Huawei, Ericsson, NEC, Samsung","Irfan Ali",50390,"CR","","","Summary of change: Introduce the decor feature based on conclusions of TR 23.707","25","6.3","Dedicated Core Networks (DECOR)",11440,"Revised","2015-05-18T06:13:47.857","2015-05-19T13:15:50.490","S2-151399","S2-151787","Rel-13","23.401","13.2.0","DECOR","2837","7","B",null,"","","","",""]
["S2-151540","Intra-decor MME offloading","NTT DOCOMO, Huawei","Irfan Ali",50390,"CR","","","Summary of change: Introduce the DECOR feature on intra-decor offloading.","25","6.3","Dedicated Core Networks (DECOR)",11520,"Merged","2015-05-18T06:13:48.077","2015-05-19T13:15:50.630","S2-150930","","Rel-13","23.401","13.2.0","DECOR","2852","1","B",null,"","","","",""]
["S2-151541","Load re-balancing for SGSNs with Dedicated Core Networks","NTT DOCOMO, Huawei","Irfan Ali",50390,"CR","","","Summary of change: Capture the solution for load balancing and load re-balancing for SGSNs when DCNs are used","25","6.3","Dedicated Core Networks (DECOR)",11580,"Revised","2015-05-18T06:13:48.247","2015-05-19T13:15:50.617","","S2-151790","Rel-13","23.236","12.0.0","DECOR","0053","","B",null,"","","","",""]
["S2-151542","WID update on DECOR","NTT DOCOMO","Irfan Ali",50390,"WID","","","Update plenary meeting number for approval","25","6.3","Dedicated Core Networks (DECOR)",11630,"Revised","2015-05-18T06:13:48.327","2015-05-19T13:15:50.583","S2-150932","S2-151791","Rel-13","","","","","","","","","","","",""]
["S2-151543","[DRAFT] Request for specification of Dedicated Core Network (DECOR) feature","NTT DOCOMO","Daisuke Fujishima",58629,"LS out","","","Ask CT WG4 and RAN WG3 to initiate the specification of DECOR feature.","25","6.3","Dedicated Core Networks (DECOR)",11650,"Revised","2015-05-18T06:13:48.327","2015-05-19T13:15:50.553","","S2-151792","Rel-13","","","","","","","",null,"CT WG4, RAN WG3"]
["S2-151544","Paging assistance information from eNB","NTT DOCOMO","Irfan Ali",50390,"CR","","","The eNB sends Paging assistance information, which is a list of recommended cells and eNBs for paging the UE to the MME that may be stored in MME and may be provided to the eNBs at paging.","40","6.20.4","TEI13 Category B/C for IMS, IMS-Related, Emergency, Other",16540,"Withdrawn","2015-05-18T06:13:48.340",null,"","","Rel-13","23.401","13.2.0","SAES, TEI13","2867","","B",null,"","","","",""]
["S2-151545","[LS Out] On Paging Optimization","NTT DOCOMO","Irfan Ali",50390,"LS out","","","Inform RAN WG3 that we have implemented CR based on their recommendation","40","6.20.4","TEI13 Category B/C for IMS, IMS-Related, Emergency, Other",16550,"Withdrawn","2015-05-18T06:13:48.417",null,"","","Rel-13","","","","","","","",null,"RAN WG3","RAN WG2, RAN WG1"]
["S2-151546","Discussion on shorten SRVCC HO voice interruption","Huawei, HiSilicon","Runze Zhou",60945,"other","","","As discussed in S2-150830 last SA WG2 meeting, there is a problem for SRVCC voice interruption time and this paper try to further discuss this issue according to online/offline comment received from last SA WG2 meeting.","16","5.4","IMS-Related Maintenance",10940,"Noted","2015-05-18T06:16:28.383","2015-05-19T12:52:34.353","","","Rel-12","","","","","","","","","","","",""]
["S2-151547","Clarification of CS user plane restoration during SRVCC HO","Huawei, HiSilicon, Intel, China Unicom","Runze Zhou",60945,"CR","","","Summary of change: Clarify in TS 23.216 that CS user plane can be resumed once the MSC receives Handover Detection message.","16","5.4","IMS-Related Maintenance",10950,"Revised","2015-05-18T06:16:28.397","2015-05-19T12:52:34.387","S2-150831","S2-151781","Rel-12","23.216","12.2.0","TEI12","0331","1","F",null,"","","","",""]
["S2-151548","Support of session continuity","CATT","Juan Zhang",38523,"pCR","","","IP preservation is supported for session continuity when the traffic switches between EPC path and relay path. IP address preservation is not supported when the remote UE moves out of the ProSe UE-to-Network relay coverage and selects another UE-Network relay.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13680,"Available","2015-05-18T06:25:31.903","2015-05-19T02:07:49.740","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151549","Architectural updates for AESE feature","China Mobile","Aihua Li",58162,"CR","","","Summary of change: Updates to architecture for AESE feature by adding new reference point Ns(RCAF- SCEF).","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12130,"Revised","2015-05-18T06:26:44.270","2015-05-19T07:34:21.300","","S2-151909","Rel-13","23.682","13.1.0","AESE","0109","","B",null,"","","","",""]
["S2-151550","Randomization attach procedure during the mobility procedure","CATT","Juan Zhang",38523,"pCR","","","UE sends NAS message in a randomization time to relieve load peak when the eNB turns on or turns off the IOPS mode and UE needs to reattach to the registered EPC.","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15720,"Noted","2015-05-18T06:27:46.780","2015-05-19T02:07:49.770","","","Rel-13","23.797","0.1.0","FS_IOPS_St2","","","","","","","","",""]
["S2-151551","Clarification on Network Triggered Service Request","LG Electronics","Jinsook Ryu",39022,"CR","","","Summary of change: - Ambiguous pronoun 'In that case' is clarified as exact case that 'When a Downlink Data Notification Reject message is received'  - Reject control signalling case also added for ISR is not activated case","13","5.1","3GPP Packet Access Maintenance",10360,"Revised","2015-05-18T06:27:48.823","2015-05-19T07:52:07.743","","S2-151889","Rel-12","23.401","12.8.0","SAES, TEI12","2868","","D",null,"","","","",""]
["S2-151552","Clarification on Network Triggered Service Request","LG Electronics","Jinsook Ryu",39022,"CR","","","Rel-13 mirror CR: Summary of change: - Ambiguous pronoun 'In that case' is clarified as exact case that 'When a Downlink Data Notification Reject message is received'  - Reject control signalling case also added for ISR is not activated case","13","5.1","3GPP Packet Access Maintenance",10380,"Revised","2015-05-18T06:32:39.763","2015-05-19T07:52:35.153","","S2-151890","Rel-13","23.401","13.2.0","SAES, TEI12","2869","","A",null,"","","","",""]
["S2-151553","Introducing SCEF and RCAF Reference Point","China Mobile","Aihua Li",58162,"CR","","","Summary of change: Add description of new reference points Ns(RCAF- SCEF) that is to be introduced in TS 23.682 as part of AESE feature.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12180,"Revised","2015-05-18T06:33:11.777","2015-05-19T07:34:21.330","","S2-151910","Rel-13","23.002","13.1.0","AESE","0284","","B",null,"","","","",""]
["S2-151554","[draft] LS on ePDG selection","TELECOM ITALIA S.p.A.","Mario Madella",23765,"LS out","","","SA WG2 kindly asks SA WG3-LI to assess whether allowing the UE to always connect to an ePDG in the home network, when roaming, could potentially violate local regulations in terms of lawful interception.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11290,"Available","2015-05-18T06:43:14.810","2015-05-18T06:46:00.343","","","Rel-13","","","","","","","","S2-151446","SA WG3-LI","CT WG1, SA WG1"]
["S2-151555","Clarification about the lifecycle of the UE context","Telecom Italia, ZTE","Mario Madella",23765,"pCR","","","This contribution proposes a clarification about the lifecycle of the UE context.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14240,"Available","2015-05-18T06:52:05.647","2015-05-18T06:54:02.070","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151556","Correction of Model B Discoveree and Discoverer UE procedures","Telecom Italia, ZTE, InterDigital","Mario Madella",23765,"pCR","","","This contribution corrects the allocation of the ProSe Query Code and clarifies which Discovery Filters are used by Discoveree and Discoverer UE.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14250,"Available","2015-05-18T06:57:30.580","2015-05-18T07:00:57.683","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151557","UE context clarification","Telecom Italia, ZTE","Mario Madella",23765,"CR","","","Summary of change: - Replaced the misleading text in step 2 of the Announce and Monitor request procedures with new text at the very end of each procedure. - Added a clarification on the behavior of the ProSe Function when the last entry is removed from the UE context.","13","5.1","3GPP Packet Access Maintenance",10660,"Revised","2015-05-18T07:08:45.757","2015-05-18T07:11:50.553","","S2-151896","Rel-12","23.303","12.4.0","ProSe-SA2","0165","","F",null,"","","","",""]
["S2-151558","Authorization information for ProSe Restricted Direct Discovery, Model A and B","Telecom Italia, Qualcomm Incorporated","Mario Madella",23765,"CR","","","Summary of change: Adding information to be provisioned to the UE for ProSe Restricted Direct Discovery authorisation and related subscription information.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14330,"Revised","2015-05-18T07:23:14.160","2015-05-18T07:25:50.007","","S2-151803","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0166","","B",null,"","","","",""]
["S2-151559","Proposed NBIFOM Technical Specification Skeleton","ZTE","Tricci So",44974,"pCR","","","This PCR is to propose the TS skeleton to be adopted and be used as the template to capture the NBIFOM Rel-13 normative text in the TR 23.861 Annex X in the interim until the designated NBIFOM TS is assigned.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11680,"Revised","2015-05-18T09:44:22.827","2015-05-18T10:12:38.470","","S2-151837","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151560","Revised NBIFOM WID for Rel-13","ZTE Corporation","Tricci So",44974,"WID","","","Revised NBIFOM WID to request for dedicated TS assignment to capture the normative procedures and also to update the conclusion date for the normative phase.","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16790,"Revised","2015-05-18T09:48:56.137","2015-05-18T10:12:38.500","","S2-151879","Rel-13","","","","","","","","","","","",""]
["S2-151561","NBIFOM Rel-13 Exception Request","ZTE","Tricci So",44974,"other","","","Rel-13 Exception Request for NBIFOM","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",12010,"Revised","2015-05-18T09:52:22.070","2015-05-18T10:12:38.547","","S2-151856","Rel-13","","","","","","","","","","","",""]
["S2-151562","3GPP resource optimizations based on providing CPs to the MME","CATT","Hucheng Wang",43301,"CR","","","Summary of change: Add the information flow of providing CP parameters to the MME; Add the functional description about enable Core Network assisted eNodeB parameters impact using CP parameters.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12210,"Merged","2015-05-18T09:54:18.100","2015-05-18T10:39:58.677","","","Rel-13","23.682","13.1.0","AESE","0110","","B",null,"","","","",""]
["S2-151563","NBIFOM TR 23.861 Cover Sheet for TR Conclusions","ZTE","Tricci So",44974,"other","","","NBIFOM Rel-13 study was concluded in SA WG2#108, this tdoc is to prepare the cover sheet to present the concluded NBIFOM TR 23.861 to SA#68 for approval","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",12040,"Revised","2015-05-18T09:54:43.310","2015-05-18T10:12:38.580","","S2-151857","Rel-13","","","","","","","","","","","",""]
["S2-151564","Specifying the protocol stack of S6t","CATT","Hucheng Wang",43301,"CR","","","Summary of change: Specifying the protocol stack of S6t.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12290,"Noted","2015-05-18T09:57:08.700","2015-05-18T10:39:58.660","","","Rel-13","23.682","13.1.0","AESE","0111","","F",null,"","","","",""]
["S2-151565","NBIFOM Call Flows - 3GPP initial & additional attach, IP flow mobility & routing rules mapping","ZTE, Alcatel-Lucent, Alcatel-Lucent Shanghai-Bell","Tricci So",44974,"pCR","","","This PCR is to propose normative text to NBIFOM call flows for procedures related to 3GPP access for initial and additional attach, IP flow mobility and routing rules mapping.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11830,"Revised","2015-05-18T09:57:38.123","2015-05-18T10:12:38.610","","S2-151846","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151566","NBIFOM Call Flows - Access Removal","ZTE","Tricci So",44974,"pCR","","","This PCR is to propose normative text to NBIFOM call flows for removing an access.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11870,"Revised","2015-05-18T09:59:03.750","2015-05-18T10:12:38.457","","S2-151847","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151567","Removal of editor's note and Conclusion on Dynamic Metadata","Huawei, Hisilicon","Runze Zhou",60945,"pCR","","","This contribution removes the editor's note and proposes the conclusion on dynamic metadata for open ProSe Direct Discovery enhancement.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14160,"Revised","2015-05-18T10:51:32.773","2015-05-19T11:30:26.563","","S2-151800","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151568","eMBMS traffic relay enhancement","Huawei, Hisilicon","Runze Zhou",60945,"pCR","","","In the existing eMBMS traffic relay solution, when the Remote UE sends a TMGI Monitoring Request to the UE-to-Network Relay, actually the Remote UE cannot know whether the TMGI corresponding eMBMS traffic can be transferred by the UE-to-Network Relay. In this contribution, an enhancement step is proposed to make sure the remote UE can always find the right UE-to-Network Relay to transfer the interested eMBMS traffic for him.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13880,"Revised","2015-05-18T10:51:32.790","2015-05-19T11:30:26.593","S2-150826","S2-151793","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151569","proximity estimation based on PC3&PC5 message combination_v4","Huawei, HiSilicon","Runze Zhou",60945,"pCR","","","Discusses a solution based on PC5&PC3 message combination for proximity estimation.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14140,"Merged","2015-05-18T10:51:32.790","2015-05-19T11:30:26.627","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151570","Authorization information for restricted discovery","Huawei, Hisilicon","Runze Zhou",60945,"CR","","","Summary of change: Adding the authorization information for the non public safety UE.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14350,"Merged","2015-05-18T10:51:32.807","2015-05-19T11:30:26.640","","","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0167","","B",null,"","","","",""]
["S2-151571","Correction to the MME selection in dedicated networks","NEC","Iskren Ianev",59515,"CR","","","Summary of change: Add the following text to the MME selection when DCN is deployed in s4.3.8.3:  If no MME from the same CN type of the MMEGI or NRI is available, the eNodeB selects a MME from the default CN and adds the MMEGI or NRI from the UE to the Initial UE message to indicate that the MME shall not reroute the NAS message as no MME of the same CN type is available.","25","6.3","Dedicated Core Networks (DECOR)",11620,"Noted","2015-05-18T10:58:39.370","2015-05-18T15:54:50.790","","","Rel-13","23.401","13.2.0","DECOR","2870","","F",null,"","","","",""]
["S2-151572","GCSE Counting using MooD Consumption Report","Qualcomm Incorporated","Haris Zisimopoulos",41602,"pCR","","","This paper proposes to use MooD consumption report as a counting mechanism for group communication system.","34","6.14","MBMS Enhancements (MBMS_enh)",15160,"Noted","2015-05-18T11:01:42.607","2015-05-19T12:54:11.107","","","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151573","ProSe Priority","Qualcomm Incorporated, Alcatel-Lucent, Intel, U.S. Department of Commerce, LG Electronics","Haris Zisimopoulos",41602,"pCR","","","Discusses options for ProSe Priority and QoS and proposes text for TR 23.713.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13530,"Revised","2015-05-18T11:01:42.623","2015-05-19T12:54:11.123","","S2-151774","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151574","Restricted ProSe Direct Discovery Model A procedures","Qualcomm Incorporated, ZTE, Telecom Italia","Haris Zisimopoulos",41602,"CR","","","Summary of change: Adding the introductions and procedure details for restricted ProSe Direct Discovery Model A procedures.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14280,"Revised","2015-05-18T11:01:42.623","2015-05-19T12:54:11.153","","S2-151801","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0168","","B",null,"","","","",""]
["S2-151575","Work Item Exception for ProSe","Qualcomm Incorporated (Rapporteur)","Haris Zisimopoulos",41602,"other","","","Exception sheet for eProSe-EXT","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13470,"Revised","2015-05-18T11:01:42.747","2015-05-19T12:54:11.200","","S2-151808","Rel-13","","","","","","","","","","","",""]
["S2-151576","Group Info in discovery message","Qualcomm Incorporated, U.S. Department of Commerce, Alcatel Lucent","Haris Zisimopoulos",41602,"pCR","","","This paper discusses the value and usage of group info in the PC5 discovery message.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13820,"Noted","2015-05-18T11:01:42.747","2015-05-19T12:54:11.247","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151577","Restricted ProSe Direct Discovery with Application-controlled extension","Qualcomm Incorporated, Interdigital, Telecom Italia","Haris Zisimopoulos",41602,"CR","","","Summary of change: Adding details for restricted ProSe Direct Discovery with application-controlled extension procedures.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14360,"Revised","2015-05-18T11:01:42.763","2015-05-19T12:54:11.293","","S2-151804","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0169","","B",null,"","","","",""]
["S2-151578","Conclusions for Enhancements to Open ProSe Direct Discovery","Qualcomm Inc.","Haris Zisimopoulos",41602,"pCR","","","This contribution proposed conclusions for the Enhancements to Open ProSe Direct Discovery.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14260,"Withdrawn","2015-05-18T11:01:42.827",null,"","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151579","Correction of UE identities used between ProSe Function for service authorization","Qualcomm Incorporated","Haris Zisimopoulos",41602,"CR","","","Summary of change: Update the procedure in 5.2.2.4 to allow either IMSI or MSISDN to be used as the UE identifier.","13","5.1","3GPP Packet Access Maintenance",10590,"Revised","2015-05-18T11:01:42.843","2015-05-19T17:14:43.420","","S2-151895","Rel-12","23.303","12.4.0","ProSe","0170","","F",null,"","","","",""]
["S2-151580","UE-to-Network Relay selection and connection establishment","Qualcomm Incorporated","Haris Zisimopoulos",41602,"pCR","","","This contribution proposed the principles for the UE-to-Network Relay selection for ProSe.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13990,"Revised","2015-05-18T11:01:42.920","2015-05-19T12:54:11.327","","S2-151797","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151581","[DRAFT] Reply LS on network feature support for ProSe Discovery","Qualcomm Inc.","Haris Zisimopoulos",41602,"LS out","","","Provides answer to CT WG1 LS on network feature support for ProSe","13","5.1","3GPP Packet Access Maintenance",10530,"Revised","2015-05-18T11:01:42.920","2015-05-19T12:54:11.357","","S2-151894","Rel-12","","","","","","","","S2-151443","CT WG1"]
["S2-151582","[DRAFT] LS on UE identity used between ProSe Functions for ProSe Service Authorization","SA WG2","Haris Zisimopoulos",41602,"LS out","","","Provides answer to CT WG4 LS on UE Identify in ProSe Authorisation procedures","13","5.1","3GPP Packet Access Maintenance",10630,"Revised","2015-05-18T11:01:42.937","2015-05-19T12:54:11.373","","S2-152066","Rel-12","","","","","","","","S2-151451","CT WG4","CT WG1, SA WG5"]
["S2-151583","Update to eDRX in Idle Mode solution","NEC","Iskren Ianev",59515,"pCR","","","Abstract of the contribution: This contribution points out at the need for synchronisation between the UE and the network in case of the extended DRX cycle length longer than the System Frame. Such a statement has already been captured in TR23.887. This contribution proposes to transfer this statement from TR23.887 to the eDRX study TR23.770. Additionally, it proposes a Note for the eDRX parameters over NAS dependence on the agreed solution for UE/network paging coordination.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15350,"Revised","2015-05-18T11:05:54.347","2015-05-18T15:55:27.700","","S2-151921","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151584","Deletion of monitoring event configuration by setting Monitoring Duration to zero","Samsung","Sung Hwan Won",46717,"CR","","","Summary of change: 1. It is clarified that Maximum Number of Reports is not sent to the HSS/MME/SGSN whereas Monitoring Duration may be sent to them. 2. Monitoring Duration is expressed in absolute time and setting it to zero means monitoring event confugration deletion. 3. If a parameter (Maximum Number of Reports or Monitoring Duration) is not included then there is no restriction on what the parameter is defined to restrict.","28","6.6","Monitoring Enhancements (MONTE)",12760,"Noted","2015-05-18T11:16:59.733","2015-05-19T11:11:49.683","","","Rel-13","23.682","13.1.0","MONTE","0112","","C",null,"","","","",""]
["S2-151585","Monitoring event configuration in the HSS and MME","Samsung","Sung Hwan Won",46717,"CR","","","Summary of change: Monitoring Event Configuration Container is added in the HSS data/MME MM contexts.","28","6.6","Monitoring Enhancements (MONTE)",12800,"Revised","2015-05-18T11:20:55.247","2015-05-19T11:11:49.713","","S2-151976","Rel-13","23.401","13.2.0","MONTE","2871","","B",null,"","","","",""]
["S2-151586","Monitoring event configuration in the HSS and SGSN","Samsung","Sung Hwan Won",46717,"CR","","","Summary of change: Monitoring Event Configuration Container is added in the HSS data/SGSN MM contexts.","28","6.6","Monitoring Enhancements (MONTE)",12830,"Revised","2015-05-18T11:22:32.653","2015-05-19T11:11:49.743","","S2-151977","Rel-13","23.060","13.2.0","MONTE","1968","","B",null,"","","","",""]
["S2-151587","Clarifications on the activation of IOPS in eNBs","Nokia Networks","György Wolfner",31366,"pCR","","","This paper proposes clarifications on the activation of IOPS in eNBs and some other minor clarifications.","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15730,"Revised","2015-05-18T11:34:09.173","2015-05-19T12:52:52.107","","S2-151927","Rel-13","23.797","0.1.0","FS_IOPS_St2","","","","","","","","",""]
["S2-151588","Removal of redundant clauses","General Dynamics UK Ltd.","Philip Young",27298,"pCR","","","This contribution proposes to remove sub-clauses from the draft TR which were included in the TR skeleton but have subsequently proved to be unnecessary or otherwise indicate that fact.","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15750,"Approved","2015-05-18T11:46:52.787","2015-05-19T11:28:18.250","","","Rel-13","23.797","0.1.0","FS_IOPS_St2","","","","","","","","",""]
["S2-151589","Subjective evaluation and comparison of FMSS solutions for key issue#1","Cisco, Allot Communications, Alcatel-Lucent, Alcatel-Lucent Shanghai-Bell, Huawei, Hisilicon, Comverse, Sprint, Openet Telecom, T-Mobile USA, Sandvine Incorporated","Nirav Salot",56645,"pCR","","","This paper proposes subjective evaluation and comparison of FMSS solutions for key issue#1.","33","6.13","Flexible Mobile Service Steering (FMSS)",15070,"Available","2015-05-18T11:48:17.980","2015-05-19T10:39:34.483","","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151590","Decouple SA2 study report from SA3 study of IOPS security solution","General Dynamics UK Ltd.","Philip Young",27298,"pCR","","","This contribution proposes text to decouple the SA WG2 study report from the SA WG3 study of an IOPS security solution","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15760,"Revised","2015-05-18T11:48:48.540","2015-05-19T11:28:18.297","","S2-151928","Rel-13","23.797","0.1.0","FS_IOPS_St2","","","","","","","","",""]
["S2-151591","Overall conclusion","Cisco, Allot Communications, Alcatel-Lucent, Alcatel-Lucent Shanghai-Bell, Huawei, Hisilicon, Comverse, Sprint, Openet Telecom, T-Mobile USA, Sandvine Incorporated","Nirav Salot",56645,"pCR","","","This paper proposes overall conclusion for the FMSS study phase.","33","6.13","Flexible Mobile Service Steering (FMSS)",15090,"Available","2015-05-18T11:50:03.403","2015-05-19T10:39:34.407","","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151592","Cover Sheet for TR 23.797 for Information and Approval at TSG SA","FS_IOPS_St2 Rapporteur (General Dynamics UK Ltd.)","Philip Young",27298,"other","","","This contribution proposes a cover page for submitting TR 23.797 to SA plenary for Information and Approval","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15810,"Revised","2015-05-18T11:51:29.737","2015-05-19T11:28:18.330","","S2-151930","Rel-13","","","","","","","","","","","",""]
["S2-151593","Updated WID for Isolated E-UTRAN Operation for Public Safety","General Dynamics UK Limited","Philip Young",27298,"WID","","","Proposal for Rel-13 stage 2 normative work to follow feature study FS_IOPS_St2","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16730,"Revised","2015-05-18T11:53:01.807","2015-05-19T11:28:18.360","","S2-151876","Rel-13","","","","","","","","","","","",""]
["S2-151594","Draft Rel-13 Work Item Exception for IOPS","FS_IOPS_St2 Rapporteur (General Dynamics UK Ltd.)","Philip Young",27298,"other","","","This contribution proposes a draft Exception Sheet to cover normative IOPS work","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15860,"Revised","2015-05-18T11:55:02.567","2015-05-19T11:28:18.390","","S2-152056","Rel-13","","","","","","","","","","","",""]
["S2-151595","Implementing AESE Solution on providing predictable communication patterns of a UE to the MME","NEC","Andreas Kunz",35384,"CR","","","Summary of change: Add functional description and information flow for providing communication pattern parameters to the MME via HSS.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12220,"Revised","2015-05-18T12:15:39.007","2015-05-19T12:51:14.777","","S2-151911","Rel-13","23.682","13.1.0","AESE","0113","","B",null,"","","","",""]
["S2-151596","HSS and MME updates for AESE 3GPP resource optimizations based on providing predictable communication patterns of a UE to the MME","NEC","Andreas Kunz",35384,"CR","","","Summary of change: Updates to the HSS and MME for the AESE solution on 3GPP resource optimizations based on providing predictable communication patterns of a UEto the MME.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12260,"Revised","2015-05-18T12:18:25.987","2015-05-19T12:51:14.747","","S2-151912","Rel-13","23.401","13.2.0","AESE","2872","","B",null,"","","","",""]
["S2-151597","MONTE: Tackling the biggies","Cisco","Maulik Vaidya",44517,"other","","","Discuss and propose way forward for 3 main issues which center around MONTE, AESE, and related work (HLcom, GROUPE etc): SCEF ownership, Roaming, Authorization levels","28","6.6","Monitoring Enhancements (MONTE)",12590,"Noted","2015-05-18T13:10:57.773","2015-05-19T05:39:01.897","","","Rel-13","","","","","","","","","","","",""]
["S2-151598","Utilizing WLAN Information for Emergency Services","Motorola Mobility","Apostolis Salkintzis",22112,"pCR","","","Discusses the information provided by WLANs related to emergency services and proposes how this information may be used by the UE. Solutions are proposed for location determination, emergency call number retrieval and WLAN selection.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16010,"Revised","2015-05-18T13:45:40.750","2015-05-19T08:00:05.220","","S2-151824","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151599","Addition of resource management for background data transfer feature","NTT DOCOMO, Huawei, Hisilicon,","Syed Husain",14749,"CR","","","Summary of change: This provides description of resource management for background data transfer.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12320,"Revised","2015-05-18T13:50:40.320","2015-05-18T17:47:25.273","","S2-151940","Rel-13","23.682","13.1.0","AESE","0114","","B",null,"","","","",""]
["S2-151600","Support for UE Consumption Reporting towards BM-SC for GCS AS","Ericsson, Qualcomm Inc.","Shabnam Sultana",21207,"CR","","","Summary of change: Introduce support of Consumption Reporting for GCS AS","39","6.20.1","TEI13 Category B/C for 3GPP Packet Access",16500,"Available","2015-05-18T13:51:56.947","2015-05-19T12:09:30.570","","","Rel-13","23.468","13.0.0","MI-MooD, TEI13","0060","","B",null,"","","","",""]
["S2-151601","MT SMS for Extended DRX","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution provides a solution for handling MT SMS for extended C-DRX","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15500,"Revised","2015-05-18T13:51:57.010","2015-05-19T12:23:50.143","","S2-151926","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151602","Extended DRX in Idle","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution provides details to the solution 5.2.1 Paging coordination between CN and UE","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15370,"Revised","2015-05-18T13:51:57.027","2015-05-19T12:23:50.173","","S2-151922","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151603","Details on how to handle report of changes of metadata over St","Ericsson","Shabnam Sultana",21207,"pCR","","","This paper proposes to remove Editors note on metadata reporting over St interface","33","6.13","Flexible Mobile Service Steering (FMSS)",14860,"Revised","2015-05-18T13:51:57.027","2015-05-19T12:23:50.190","","S2-151936","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151604","Clarification on solution for background traffic","Ericsson","Shabnam Sultana",21207,"pCR","","","Clarifications to the general approach to align with current PCC specifications.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12100,"Revised","2015-05-18T13:51:57.040","2015-05-19T12:25:38.687","","S2-151907","Rel-13","23.708","1.1.0","AESE","","","","","","","","",""]
["S2-151605","Evaluation of paging strategy solutions for Idle mode Issue 2","Ericsson","Shabnam Sultana",21207,"pCR","","","Evaluates paging strategy solutions for idle mode Issue 2, and concludes that coordinated UE and CN solution is more efficient and reliable.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15440,"Available","2015-05-18T13:51:57.040","2015-05-19T12:23:50.220","","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151606","GTP-C re-transmissions","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution updates a solution for GTP-C re-transmissions and provides an evaluation of the two available solutions","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15450,"Revised","2015-05-18T13:51:57.057","2015-05-19T13:22:18.510","","S2-151924","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151607","Group Priority","Ericsson","Shabnam Sultana",21207,"pCR","","","Provides solution for group priority for public safety device communications","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13570,"Noted","2015-05-18T13:51:57.057","2015-05-18T19:24:32.200","S2-150812","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151608","Introduce the Dedicated Core Network (DECOR) feature","Ericsson, TeliaSonera, AT&T","Shabnam Sultana",21207,"CR","","","Summary of change: Revision 8 includes the following corrections to S2-151399 rev 6: - Clause 3.2: The DCN acronym is introduced. - On a number of places CN is changed to DCN - Clause 4.3.x.1: Selection of default DCN not mandatory at insufficient information. - Rearranged order of chapter 4.3.8 and 4.3.7. - Clause 4.3.8.3 & 4.3.8.4: Selection of same DCN not mandatory at selection from  source SGSN/MME. - Clause 5.x.1: Clarification that NAS Message Redirection Procedure is used by HSS  initiated Core Network Reselection procedure. - Clause 5.x.1 step 1: Modified parameter description to avoid sending of NAS Request  message twice. Referring to original RAN message makes it future proof. - Clause 5.x.1 step 2: Replaced 'shall' by 'should' considering that success is not  guaranteed. Changed 'PLMN selected' to 'selected operator' to also cover the case of  non-supporting UEs in a shared network. - Clause 5.x.2: Missing references. - Clause 5.x.2 step 2: Aligned with clause 5.","25","6.3","Dedicated Core Networks (DECOR)",11430,"Merged","2015-05-18T13:51:57.073","2015-05-19T12:44:49.780","S2-151399","","Rel-13","23.401","13.2.0","DECOR","2837","8","B",null,"","","","",""]
["S2-151609","Conclusion for FS-SEW phase 1","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","Proposes conclusions for the phase 1 of the FS-SEW study","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16220,"Revised","2015-05-18T14:50:20.407","2015-05-19T12:13:53.637","","S2-151841","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151610","Removal of UE-to-Network Relay text","LG Electronics, Qualcomm Incorporated, Nokia Networks","Laeyoung Kim",40613,"CR","","","Summary of change: UE-to-Network Relay related text is removed.","13","5.1","3GPP Packet Access Maintenance",10580,"Noted","2015-05-18T14:52:32.913","2015-05-19T06:18:14.617","","","Rel-12","23.303","12.4.0","ProSe","0171","","D",null,"","","","",""]
["S2-151611","NAS-level indication related to ProSe Direct Discovery support","LG Electronics","Laeyoung Kim",40613,"CR","","","Summary of change: New indication is included in the Attach/TAU Accept to clearly inform the UE of support of ProSe Direct Discovery in the serving PLMN so that unnecessary ProSe signalling from the UE to the ProSe Function can be avoided when the UE selects a PLMN in which the ProSe Direct Discovery feature was disabled by the operator. The MME shall set a 'ProSe Direct Discovery supported Indication' while taking into account that the ProSe Direct Discovery service is enabled in the network.","13","5.1","3GPP Packet Access Maintenance",10560,"Available","2015-05-18T14:56:44.120","2015-05-19T10:24:40.343","","","Rel-12","23.303","12.4.0","ProSe","0172","","F",null,"","","","",""]
["S2-151612","Clarification on TMGI advertisement procedure and resolving the related FFS","LG Electronics","Laeyoung Kim",40613,"pCR","","","This P-CR clarifies TMGI advertisement procedure and resolves the related FFS.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13900,"Available","2015-05-18T14:59:41.883","2015-05-19T10:24:40.483","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151613","UE-to-Network Relay release procedure","LG Electronics","Laeyoung Kim",40613,"pCR","","","This P-CR proposes UE-to-Network Relay release procedure.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13970,"Revised","2015-05-18T15:01:35.233","2015-05-19T10:24:40.530","","S2-151796","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151614","General Monitoring Issues","Ericsson","Shabnam Sultana",21207,"pCR","","","Identifying some issues related to MONTE and proposing resolution","28","6.6","Monitoring Enhancements (MONTE)",12610,"Available","2015-05-18T15:37:19.723","2015-05-19T13:23:12.830","","","Rel-13","23.789","13.0.0","MONTE","","","","","","","","",""]
["S2-151615","Concluding on the Solution 7.2.1: WebRTC related IMS service control","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","Updates the solution 7.2.1and proposes a conclusion on the support of WebRTC related IMS service control","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13110,"Revised","2015-05-18T16:44:34.097","2015-05-19T12:16:01.527","","S2-151830","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151616","Support of Service Continuity for Public Safety","Deutsche Telekom, Alcatel Lucent, Intel, BlackBerry, Samsung, Nokia Networks","Michele Zarri",20505,"pCR","","","This contribution proposes to document in TR 23.713 that IP service continuity for ProSe Public Safety will not be specified in Release 13","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13650,"Revised","2015-05-18T17:03:23.730","2015-05-19T05:44:23.837","","S2-151771","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151617","Conclusion for IOPS study","Samsung, General Dynamics UK Ltd., Nokia Networks","Curt Wong",42596,"pCR","","","This paper is trying to conclude TR 23.797 and to allow normative phase to be started at next meeting (assuming exception is granted by TSG SA).","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15790,"Revised","2015-05-18T20:26:02.137","2015-05-19T05:57:31.383","","S2-151929","Rel-13","23.797","0.1.0","FS_IOPS_St2","","","","","","","","",""]
["S2-151618","Conclusion on eWebRTC and IUT","Samsung","Curt Wong",42596,"pCR","","","This paper proposes a conclusion to the interaction on IUT and webRTC.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13160,"Merged","2015-05-18T20:37:38.583","2015-05-19T05:57:31.413","","","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151619","HLcom solution Using Monitoring Event 'Availability after DDN Failure'","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Mike Dolan",1692,"CR","","","Summary of change: Soution 4 in TR 23.709 'Availability Notification after DDN Failure' is added to TS 23.682.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14590,"Revised","2015-05-18T21:57:48.020","2015-05-18T22:00:39.620","","S2-151981","Rel-13","23.682","13.1.0","HLcom","0115","","B",null,"","","","",""]
["S2-151620","Solutions for Key issue 5","T-Mobile USA","Christopher Joul",31136,"pCR","","","This document describes three solutions for FS_SEW related to key issue 5","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16040,"Revised","2015-05-18T22:08:00.373","2015-05-18T23:50:06.007","","S2-151834","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151621","Discussion on Location Based ePDG Selection","Rogers Communications, China Mobile, Intel, Qualcomm Incorporated","Alexander Markman",35093,"other","","","The contribution discusses requirements for supporting location based ePDG selection and proposes a solution enabling such selection.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11260,"Noted","2015-05-18T23:31:35.837","2015-05-19T00:59:09.643","","","","","","","","","","","","","","",""]
["S2-151622","Location Based ePDG Selection","Rogers Communications, China Mobile, Intel Corporation, Qualcomm Incorporated","Alexander Markman",35093,"CR","","","Summary of change: Including Tracking/Location Area Identity information into ePDG FQDN enables selecting ePDG geographically or topologically close to the UE, which in turn enables optimal P-GW selection for the connection.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11270,"Noted","2015-05-18T23:50:21.547","2015-05-19T12:00:40.663","","","Rel-13","23.402","13.1.0","TEI13","1362","","F",null,"","","","",""]
["S2-151623","Solution for key issue #3: UE-based location via SIP for untrusted WLAN","Apple Inc.","Krisztian Kiss",57762,"pCR","","","This P-CR proposes to add a new solution for Key Issue 3 (Providing location information to IMS nodes).","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15970,"Withdrawn","2015-05-19T00:46:00.133",null,"","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151624","Discussion for unusable indication of the 3GPP access in SCM","LG Electronics","Maurice Pope",648,"pCR","","","This contribution proposes to discuss about the 3GPP access loss indication when the UE is connected on s2a with SCM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11990,"Noted","2015-05-19T01:02:09.203","2015-05-19T04:42:34.127","","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151625","Unusable indication procedure in SCM","LG Electronics","Maurice Pope",648,"pCR","","","This P-CR proposes the procedure for the 3GPP access loss indication in Single-connection mode.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",12000,"Available","2015-05-19T01:02:09.217","2015-05-19T04:42:34.160","","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151626","Clarification on inapplicability of RAN rule in case of a multi-access PDN connection","LG Electronics","Hyunsook Kim",42013,"CR","","","Summary of change: Adding the following clarification  Traffic steering decisions using procedures defined in TS 36.304 [34] are not applicable to a multi-access PDN connection (i.e. a PDN connection established over multiple accesses using the same APN) established by means of static pre-configuration policy.","15","5.3","Non-3GPP Access Maintenance",10870,"Noted","2015-05-19T02:27:43.077","2015-05-19T04:15:01.520","","","Rel-12","23.401","12.8.0","UTRA_LTE_WLAN_interw-SA2","2873","","F",null,"","","","",""]
["S2-151627","Clarification on inapplicability of RAN rule in case of a multi-access PDN connection","LG Electronics","Hyunsook Kim",42013,"CR","","","Rel-13 mirror CR: Summary of change: Adding the following clarification  Traffic steering decisions using procedures defined in TS 36.304 [34] are not applicable to a multi-access PDN connection (i.e. a PDN connection established over multiple accesses using the same APN) established by means of static pre-configuration policy.","15","5.3","Non-3GPP Access Maintenance",10880,"Noted","2015-05-19T02:27:43.170","2015-05-19T04:15:01.553","","","Rel-13","23.401","13.2.0","UTRA_LTE_WLAN_interw-SA2","2874","","A",null,"","","","",""]
["S2-151628","[draft] LS on inapplicability of RAN rule in case of a multi-access PDN connection","LG Electronics","Hyunsook Kim",42013,"LS out","","","SA WG2 kindly requests CT WG1 and RAN WG2 to take into account the agreed TS 23.401 CR, and to clarify it in the corresponding specifications (if need).","15","5.3","Non-3GPP Access Maintenance",10890,"Noted","2015-05-19T02:27:43.233","2015-05-19T04:15:01.583","","","Rel-12","","","","","","","",null,"CT WG1, RAN WG2"]
["S2-151629","Relationship between RAN rules and NBIFOM","LG Electronics","Hyunsook Kim",42013,"pCR","","","This paper considers the relationship between RAN rules and NBIFOM further.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11930,"Merged","2015-05-19T02:27:43.233","2015-05-19T04:15:01.630","","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151630","NBIFOM system impacts","LG Electronics","Hyunsook Kim",42013,"pCR","","","This paper considers NBIFOM system impacts","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11920,"Merged","2015-05-19T02:27:43.247","2015-05-19T04:15:01.660","","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151631","Clarification on inapplicability of RAN rule in case of a multi-access PDN connection","LG Electronics","Hyunsook Kim",42013,"CR","","","Summary of change: Adding the following clarification  Traffic steering decisions using procedures defined in TS 25.304 are not applicable to a multi-access PDN connection (i.e. a PDN connection established over multiple accesses using the same APN) established by means of static pre-configuration policy.","15","5.3","Non-3GPP Access Maintenance",10900,"Noted","2015-05-19T03:03:05.863","2015-05-19T04:15:01.693","","","Rel-12","23.060","12.8.0","UTRA_LTE_WLAN_interw-SA2","1969","","F",null,"","","","",""]
["S2-151632","Clarification on inapplicability of RAN rule in case of a multi-access PDN connection","LG Electronics","Hyunsook Kim",42013,"CR","","","Rel-13 mirror CR: Summary of change: Adding the following clarification  Traffic steering decisions using procedures defined in TS 25.304 are not applicable to a multi-access PDN connection (i.e. a PDN connection established over multiple accesses using the same APN) established by means of static pre-configuration policy.","15","5.3","Non-3GPP Access Maintenance",10910,"Noted","2015-05-19T03:03:05.957","2015-05-19T04:15:01.770","","","Rel-13","23.060","13.2.0","UTRA_LTE_WLAN_interw-SA2","1970","","A",null,"","","","",""]
["S2-151633","Proposed Solution B for Key Issue 1 using MBSFN Area Id and/or ECGI list","Motorola Solutions","Val Oprescu",14981,"pCR","","","This contribution proposes a solution for Key issue 1 for Rel-13 which preserves (from Rel-12) the capability of the Application/GCS AS to indicate (rather than rely on RAN-level guesses) which kind of bearer and exactly which area of distribution for the bearer is to be used. The proposal employs MBSFN Area Ids in lieu of service areas and SAIs, to request/modify service. ECGI lists can be used for SC-PTM.","34","6.14","MBMS Enhancements (MBMS_enh)",15170,"Revised","2015-05-19T03:38:06.803","2015-05-19T05:26:10.777","S2-150988","S2-151886","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151634","Proposed text for Sections 7 & 8 - Overall Evaluation and Conclusions","Motorola Solutions","Val Oprescu",14981,"pCR","","","This contribution provides a direct comparison of Solution 1 and Solution B, and proposes a way forward.","34","6.14","MBMS Enhancements (MBMS_enh)",15290,"Available","2015-05-19T03:49:58.030","2015-05-19T05:26:10.793","","","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151635","Proposed new key issue: Update of MBMS design requirements for Public Safety","Motorola Solutions","Val Oprescu",14981,"pCR","","","Not handled at Cabo. It is necessary to clarify which functional limitations need to be lifted and what options need to be selected to enable support of Public Safety functionality.","34","6.14","MBMS Enhancements (MBMS_enh)",15200,"Noted","2015-05-19T03:56:42.957","2015-05-19T05:26:10.810","S2-151020","","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151636","Change of name for parameter FlowID","Motorola Solutions","Val Oprescu",14981,"CR","","","Summary of change: Replace the parameter name 'FlowID' with 'Tag' in messages on the MB2 interface. Some editorials corrected (Figure numbering).","13","5.1","3GPP Packet Access Maintenance",10760,"Revised","2015-05-19T04:53:36.047","2015-05-19T05:26:10.840","","S2-151918","Rel-12","23.468","12.4.0","GCSE_LTE","0061","","F",null,"","","","",""]
["S2-151637","Change of name for parameter FlowID","Motorola Solutions","Val Oprescu",14981,"CR","","","Rel-13 mirror CR: Summary of change: Replace the parameter name 'FlowID' with 'Tag' in messages on the MB2 interface. Some editorials corrected (Figure numbering).","13","5.1","3GPP Packet Access Maintenance",10780,"Available","2015-05-19T05:01:06.767","2015-05-19T05:26:10.857","","","Rel-13","23.468","13.0.0","GCSE_LTE","0062","","A",null,"","","","",""]
["S2-151638","option for Gx solution","KDDI Corporation","Takeshi Usui",59388,"pCR","","","-","33","6.13","Flexible Mobile Service Steering (FMSS)",15140,"Withdrawn","2015-05-19T05:12:18.077",null,"","S2-151738","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151639","[DRAFT] LS on Communication Pattern parameters provisioning for MTC","Samsung","Sung Hwan Won",46717,"LS out","","","SA WG2 introduced the Communication Pattern parameters provisioning procedure within the Architecture Enhancements for Service Capability Exposure work item. SA WG2 acknowledges the LS (R1-145454) on paging for MTC and its reply LSs. The procedure allows the MME to be aware whether the UE is stationary or not, that is, it is identified that there is a certain case where sending the S1: PAGING message to the last used eNB is beneficial. Add to this, SA WG2 finds it advantageous to optionally include the ECGI of the last serving cell in the S1: PAGING message. SA WG2 further wants to ask the following question: Is it feasible that the SCS/AS is aware of the UE's coverage situation? If the answer is yes, this may imply that the UE is able to send its coverage situation to the SCS/AS via application-layer signaling.","39","6.20.1","TEI13 Category B/C for 3GPP Packet Access",16440,"Available","2015-05-19T05:32:10.300","2015-05-19T11:11:49.777","","","Rel-13","","","","","","","",null,"RAN WG2, RAN WG3","RAN WG1"]
["S2-151640","Proposed new Key Issue: 'MBMS Congestion' Mitigation for Rel-13","Motorola Solutions","Val Oprescu",14981,"pCR","","","Proposes the addition of the Key Issue to study for MBMS congestion management in Rel-13","34","6.14","MBMS Enhancements (MBMS_enh)",15210,"Revised","2015-05-19T05:36:51.260","2015-05-19T05:41:09.287","S2-151083","S2-151915","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151641","Clarification of dual classifier solution","China Mobile, CATR","Tao Sun",54129,"pCR","","","Provide clarification of the dual classifier solution","33","6.13","Flexible Mobile Service Steering (FMSS)",14710,"Revised","2015-05-19T05:59:29.227","2015-05-19T06:30:14.570","","S2-151897","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151642","Update to Solution 2 : DL data buffering in S-GW or Gn-SGSN","CATT","Ming Ai",40862,"pCR","","","This contribution proposes that how MME keeps the condition whether buffered data packets exist in S-GW.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14420,"Noted","2015-05-19T06:11:19.260","2015-05-19T06:30:14.603","","","Rel-13","23.709","1.2.0","FS_HLcom","","","","","","","","",""]
["S2-151643","FMSS Rel-13 Exception Request","CHINA MOBILE","Tao Sun",54129,"pCR","","","Rel-13 Exception Request for FMSS","33","6.13","Flexible Mobile Service Steering (FMSS)",15110,"Revised","2015-05-19T06:14:24.617","2015-05-19T06:30:14.617","","S2-152053","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151644","LS from RAN WG1: LS on public safety discovery","RAN WG1","Maurice Pope",648,"LS in","","","RAN WG1 has made the following agreement at RAN WG1 #80BIS: Agreement: - For partial and outside network coverage discovery, PSDCH transmission is supported when PSDCH resources are (pre)configured. - Relevant discovery pool parameters are preconfigured for out of coverage operation - Details FFS - The transport block size on the PSDCH is 232 bits (excluding 24 CRC bits) both for in and out of coverage operation - Note: From RAN WG1 perspective, this doesn't preclude a discovery payload above L1 > 232 bits","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13700,"Treated","2015-05-19T06:22:49","2015-05-19T06:30:14.647","","","Rel-13","","","","","","","",null,null,null,"R1-152422","S2-151813"]
["S2-151645","LS from RAN WG1: LS on D2D priority handling","RAN WG1","Maurice Pope",648,"LS in","","","RAN WG1 has discussed the possibility of associating Mode 2 SA and data resource pools to application/group/user priorities. RAN WG1would like to ask RAN WG2 whether this can fulfil the requirements, and if not, whether RAN WG2 is looking at solutions to handle different priorities","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13500,"Noted","2015-05-19T06:22:49.017","2015-05-19T06:30:14.680","","","Rel-13","","","","","","","",null,null,null,"R1-152423"]
["S2-151646","LS from RAN WG2: Reply LS on public safety discovery","RAN WG2","Maurice Pope",648,"LS in","","","RAN WG2 would like to thank SA WG2 for the liaisons on public safety discovery. RAN WG2 has discussed the suitability of PC5 Signaling Protocol for public safety discovery, TMGI advertisement and Cell ID announcement procedures from RAN WG2 perspective. RAN WG2 recognizes that if the size of the discovery messages for public safety discovery procedure (i.e. Section 6.1.2 in TR 23.713) can be restricted to 232 bits (in total for upper layer and potential AS layer information still under consideration in RAN WG2), the discovery transport (PC5-D) can be used. If this restriction is not feasible, RAN WG2 did not agree on any further guidance compared to what RAN WG1 already expressed in R1-150948. For all the other procedures (i.e. TMGI advertisement and Cell ID annoucement procedures) RAN WG2 is still evaluating. From RAN WG2 point of view, it would be desirable if the discovery message size could be kept as low as possible. Action: RAN WG2 would like to ask SA WG2 to take the a","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13690,"Treated","2015-05-19T06:22:49.017","2015-05-19T06:30:14.367","","","Rel-13","","","","","","","",null,null,null,"R2-151723","S2-151813"]
["S2-151647","LS from RAN WG2: Reply LS on RAN assumptions from SA2 for FS_eDRX","RAN WG2","Maurice Pope",648,"LS in","","","RAN WG2 would like to thank SA WG2 for their LS on RAN assumptions for FS_eDRX. This reply LS is related to the HSPA study item 'Study on Small Data Transmission Enhancements for UMTS', i.e. does not apply to LTE. The LTE work item 'RAN enhancements for extended DRX in LTE' will start in RAN WG2#90. RAN WG2 is studying extending the DRX for HSPA. However RAN WG2 needs more time to discuss the extended DRX solution to answers the issues identified by SA WG2 (issues 1-3 in LS (R2-151028/S2-151430)). RAN WG2 intends to comeback on those issues at a later point in time. RAN WG2 would like to inform SA WG2 that as a result of the study in SA WG2, RAN WG2 agreed to study an extended DRX (beyond the SFN limit of 40.96 seconds) but also a longer DRX up to 40.96 seconds (within the SFN limit) for both Idle and Connected mode. Action: RAN WG2 kindly asks SA WG2 to take this information into account.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15700,"Postponed","2015-05-19T06:22:49.033","2015-05-19T06:30:14.400","","S2-152145","Rel-13","","","","","","","",null,null,null,"R2-151735"]
["S2-151648","LS from RAN WG2: Reply LS on PLMN reselection for ProSe","RAN WG2","Maurice Pope",648,"LS in","","","RAN WG2 would like to thank CT WG1 for the reply LS in C1-151606 on PLMN selection for ProSe.  RAN WG2 discussed the questions in the reply LS and provide the following answers: CT 1 question:  Whether AS layer can report to NAS the PLMN ID(s) advertised by the cell operating in the radio resources provisioned to the UE and for each of these PLMNs, whether the PLMN provides radio resources for ProSe direct communication. RAN WG2 answer:  UE can identify PLMN ID(s) and radio resources for ProSe direct communication, if any, from system information broadcast by a cell on ProSe carrier that is provisioned to UE. Therefore AS layer can report to NAS the PLMN ID(s) obtained from the ProSe carrier, and it can also indicate whether the reported PLMN provides radio resources for ProSe direct communication.  It is noted in Rel-12 that there is only one ProSe carrier provisioned to a UE, and that the radio resources for ProSe direct communication are common to all PLMNs broadcast by th","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13510,"Noted","2015-05-19T06:22:49.047","2015-05-19T06:30:14.447","","","Rel-12","","","","","","","",null,null,null,"R2-151784"]
["S2-151649","LS from RAN WG2: LS reply on paging for MTC","RAN WG2","Maurice Pope",648,"LS in","","","RAN WG2 would like to thank RAN WG1 for its liaison statement on paging for Rel-13 low complexity UEs and/or UEs in enhanced coverage. RAN WG2 has noted the observations that RAN WG1 made in their LS and discussed the questions from SA WG2 in R2-150026/S2-150697. RAN WG2 has agreed that Rel-13 'normal complexity' UEs in enhanced coverage will be paged using the same mechanism for paging Rel-13 'low complexity' UEs. RAN WG2 would like to provide the following answers:  Question 1. Is the eNB expected to determine the required amount of coverage enhancement techniques based only on static information (such as UE radio capability) or also dynamic information e.g. whether they are in good or bad coverage?  RAN WG2 agreed that both UE radio capability (Rel-13 low complexity and/or enhanced coverage capability) and information about UE's enhanced coverage level are used in the eNB to determine the amount of coverage enhancement techniques required.  Question 2. Is there benefit to","6","4.1","Common issues and Incoming LSs",10120,"Postponed","2015-05-19T06:22:49.047","2015-05-19T06:30:14.477","","S2-152146","Rel-13","","","","","","","",null,null,null,"R2-151786"]
["S2-151650","LS from RAN WG2: LS on ProSe Priorities","RAN WG2","Maurice Pope",648,"LS in","","","One of the objectives of the Rel-13 ProSe WI is 'Priority of different groups support'. RAN WG2 started discussing this aspect but struggled to understand the relevant requirements that may drive the overall QoS/Priority solution in RAN WG2. RAN WG2 discussed priority handling for ProSe, including the notion of 'group priority', and whether and how it should be realized at Access Stratum layer. The answer to the following questions may establish a common understanding: Question 1: Is it required that a single UE be able to transmit packets of different priorities on the PC5 interface? Or is there just one priority level applicable to all packets originating from a UE? Question 2: If a single UE can transmit packets of different priorities, is the Access Stratum supposed to transmit packets preferentially taking priority into account? Or are the different priorities handled solely within the higher layers? Question 3: If multiple UEs (including the case of multiple UEs from di","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13520,"Treated","2015-05-19T06:22:49.063","2015-05-19T06:30:14.507","","","Rel-13","","","","","","","",null,null,null,"R2-151789","S2-151810"]
["S2-151651","LS from SA WG3LI: Reply LS on VoLTE Roaming Architecture","SA WG3LI","Maurice Pope",648,"LS in","","","SA WG3 LI would like to thank GSMA PSMC for their LS on VoLTE Roaming architecture. SA WG3 LI identified that LI in VPLMN for inbound roamers is the issue, and that LI in HPLMN for outbound roamers is not an issue. SA WG3 LI also identified that LI in HPLMN on behalf of VPLMN across jurisdictions will not meet requirements. SA WG3 LI understands that there are countries (e.g. Japan) in which the national regulations' LI requirement may be met possibly using LI capabilities not specified by 3GPP in case of S8HR without further work by 3GPP, and that there are countries (e.g. France) in which the national regulations lead to further work by 3GPP, based on current LI capabilities as defined in 3GPP specifications.  SA WG3 LI understands that there are national regulations that lead to the requirement that S8HR scenario can only be deployed when there is no confidentiality protection for all inbound roamers only at the point of interception in the VPLMN. For these cases there is","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10160,"Noted","2015-05-19T06:22:49.063","2015-05-19T06:30:14.540","","","","","","","","","","",null,null,null,"S3i150145"]
["S2-151652","LS from SA WG3LI: Reply to LS on VoLTE Roaming Architecture GSMA","SA WG3LI","Maurice Pope",648,"LS in","","","GSMA NG requested SA WG3-LI to review the S8HR candidate roaming architecture, consider the LI service impacts and indicate the scope of the work to address those impacts. This Liaison Statement response describes the initial set of issues affecting the LI service currently specified by 3GPP when S8HR roaming is deployed. It also lists the initial set of tasks that SA WG3-LI has identified to develop the support required for a 3GPP LI service to handle S8HR roaming scenarios.","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10170,"Noted","2015-05-19T06:22:49.080","2015-05-19T06:43:37.670","","","Rel-13","","","","","","","",null,null,null,"S3i150153"]
["S2-151653","LS from SA WG3LI: Reply LS on OMR-based solution in eWebRTCi","SA WG3LI","Maurice Pope",648,"LS in","","","LS to SA WG3-LI. OMR had been specified in 3GPP Release 10 to avoid unnecessary media anchoring. SA WG2 has conditionally endorsed the OMR-based solution in 8.2.2 for the key issue: Architectural aspects for minimizing the need for bearer level protocol conversion between two WebRTC peers. In that solution, if Lawful Interception is required for a specific WebRTC user, the OMR will be disabled by eP-CSCF for that user. However, there is still concern whether this solution can meet the Lawful Interception requirement. SA WG2 asks SA WG3-LI: Q1: Does the OMR based solution, as described above for WebRTC users, meet the Lawful Interception requirement? A: One of the central requirements of LI is for transparency to be maintained. That is, it should not be perceptible to any party not authorized to be aware of LI. Disabling OMR on a per-target basis might raise transparency issues. As long as the requirements of Q.2.2 of TS 23.228, 3rd bullet of the 3rd paragraph, as copied below","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13190,"Noted","2015-05-19T06:22:49.097","2015-05-19T06:43:37.700","","","Rel-13","","","","","","","",null,null,null,"S3Li150154"]
["S2-151654","LS from SA WG4: Reply LS on TR 26.924 Study on improved end-to-end QoS handling","SA WG4","Maurice Pope",648,"LS in","","","SA WG4 thanks SA WG2, CT WG1, CT WG3 and CT WG4 for their reply LSs in S2-151425, C1-151042, C3-150450/S4-150284 and C4-150685, respectively. SA WG4 appreciates the detailed review and provides answers to the received comments below, where requested. [...] Action: SA WG2, CT WG1, CT WG3 and CT WG4 are requested to review the TR and provide feedback where needed.","21","6.1.2","Rel-13 PCC/QoS Maintenance",11080,"Treated","2015-05-19T06:22:49.097","2015-05-19T06:43:37.730","","","Rel-13","","","","","","","",null,null,null,"S4-AHM259","S2-151829"]
["S2-151655","Conclusion on Service continuity between Network and ProSe UE-to-Network relays","Alcatel-Lucent, Intel, BlackBerry, Deutsche Telekom, Samsung, Nokia Networks","Alessio Casati",13542,"other","","","this contribution attempts to conclude on the topic of Service continuity between Network and ProSe UE-to-Network relays","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13670,"Withdrawn","2015-05-19T06:31:10.577","2015-05-19T08:22:10.597","","","Rel-13","","","","","","","","","","","",""]
["S2-151656","On Prose UE-to-Network Relay discovery","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Qualcomm Incorporated.","Alessio Casati",13542,"pCR","","","This paper focuses on the discovery of a relay suitable to offer a desired connectivity.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13770,"Revised","2015-05-19T06:34:28.463","2015-05-19T08:22:10.567","","S2-151777","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151657","On the e-CDRX period","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Alessio Casati",13542,"pCR","","","This paper addresses the need to identify the expected range of the e-CDRX before we move to normative phase, in order to have a stable selection criterion for solutions.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15540,"Revised","2015-05-19T06:39:08.660","2015-05-19T08:22:10.613","","S2-151932","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151658","Work item on MBMS Enhancements","Nokia Networks","Rainer Liebhart",13470,"WID","","","New Rel-13 WID on MBMS Enhancements.","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16750,"Revised","2015-05-19T06:51:08.780","2015-05-19T08:13:56.697","","S2-151877","Rel-13","","","","","","","","","","","",""]
["S2-151659","Discussion on ePDG selection","Qualcomm Incorporated","Faccin Stefano",60610,"other","","","This discussion paper points out issues raised by GSMA and carriers wrt the current ePDG solution. It addresses the shortcoming of the current solution wrt the needs of the market and realistic deployments and proposes a way to address such issues.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11200,"Available","2015-05-19T07:02:27.357","2015-05-19T07:49:52.990","","","Rel-13","","","","","","","","","","","",""]
["S2-151660","Discussion on how to avoid QCI 1 bearer","ZTE","Zhendong Li",38521,"pCR","","","This paper discusses solutions on how to avoid QCI I bearer establishment and suggest a proposal","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13290,"Noted","2015-05-19T07:10:28.467","2015-05-19T08:56:20.830","","","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151661","eP-CSCF behavior to avoid SRVCC","ZTE","Zhendong Li",38521,"CR","","","Summary of change: If the operator wants to avoid SRVCC in WebRTC, the eP-CSCF is configured with specific AF application identifier used in PCC procedure.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13300,"Merged","2015-05-19T07:10:28.483","2015-05-19T08:56:20.847","","","Rel-13","23.228","13.2.0","eWebRTCi","1132","","B",null,"","","","",""]
["S2-151662","Configuring AF application identifier value in PCRF to avoid SRVCC","ZTE","Zhendong Li",38521,"CR","","","If the operator wants to avoid SRVCC in WebRTC, the AF and PCRF should be configured with same specific AF application identifier used in PCC procedure to avoid QCI I bearer establishment.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13440,"Withdrawn","2015-05-19T07:10:28.593",null,"","","Rel-13","23.706","0.3.0","eWebRTCi","0001","","B",null,"","","","",""]
["S2-151663","Discussion on LI and E2E media transport","ZTE","Zhendong Li",38521,"pCR","","","This paper discusses the relation between LI and E2E media transport, and concludes that LI does not apply for E2E media.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13220,"Revised","2015-05-19T07:10:28.670","2015-05-19T08:56:20.877","","S2-151833","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151664","Using OMR for WebRTC E2E media transport","ZTE","Zhendong Li",38521,"CR","","","Summary of change: The eP-CSCF should apply OMR to achieve the End to End media transport.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13370,"Revised","2015-05-19T07:10:28.670","2015-05-19T08:56:20.893","","S2-151852","Rel-13","23.228","13.2.0","eWebRTCi","1133","","B",null,"","","","",""]
["S2-151665","Conclusion for informing about UE's connection properties","Huawei, HiSilicon","Mirko Schramm",23396,"pCR","","","This contribution proposes a conclusion for the solution.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12120,"Noted","2015-05-19T07:15:14.827","2015-05-19T13:28:51.727","","","Rel-13","23.708","1.1.0","AESE","","","","","","","","",""]
["S2-151666","Dual connectivity handling for the failed E-RAB(s)","Huawei, Hisilicon","Runze Zhou",60945,"CR","","","Summary of change: Add the Dual connectivity handling for the failed E-RAB(s) in the E-RAB Modification procedure","13","5.1","3GPP Packet Access Maintenance",10300,"Revised","2015-05-19T07:18:54.287","2015-05-19T11:10:51.570","","S2-151887","Rel-12","23.401","12.8.0","TEI12, LTE_SC_enh_dualC","2875","","F",null,"","","","",""]
["S2-151667","Dual connectivity handling for the failed E-RAB(s)","Huawei, Hisilicon","Runze Zhou",60945,"CR","","","Rel-13 mirror CR: Summary of change: Add the Dual connectivity handling for the failed E-RAB(s) in the E-RAB Modification procedure","13","5.1","3GPP Packet Access Maintenance",10320,"Revised","2015-05-19T07:18:54.367","2015-05-19T11:10:51.603","","S2-151888","Rel-13","23.401","13.2.0","TEI12, LTE_SC_enh_dualC","2876","","A",null,"","","","",""]
["S2-151668","Clarification of Group specific NAS Level congestion control","Huawei","Runze Zhou",60945,"CR","","","Summary of change: Remove 'same APN information is sent to the UE in the rejection message'.","29","6.7","Group based Enhancements (GROUPE)",12980,"Revised","2015-05-19T07:18:54.443","2015-05-19T11:10:51.633","","S2-151883","Rel-13","23.401","13.2.0","GROUPE","2877","","F",null,"","","","",""]
["S2-151669","Clarification of Group specific NAS Level congestion control","Huawei","Runze Zhou",60945,"CR","","","Summary of change: Remove 'same APN information is sent to the UE in the rejection message'.","29","6.7","Group based Enhancements (GROUPE)",13000,"Revised","2015-05-19T07:18:54.507","2015-05-19T11:10:51.650","","S2-151884","Rel-13","23.060","13.2.0","GROUPE","1971","","F",null,"","","","",""]
["S2-151670","solution evaluation on GTP-C retransmission","Huawei","Runze Zhou",60945,"pCR","","","solution evaluation on GTP-C retransmission","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15480,"Revised","2015-05-19T07:18:54.600","2015-05-19T11:10:51.680","","S2-151925","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151671","OMR handling of SDP offer-answer exchanges after media path has been selected","Nokia Networks, Ericsson","Martin Oettl",17230,"CR","","","Summary of change: In subsequent SDP offer-answer exchanges, OMR procedures shall not change the media path. Details of those procedures are left for stage 3 work.","16","5.4","IMS-Related Maintenance",10970,"Revised","2015-05-19T07:19:28.517","2015-05-19T07:41:23.907","S2-150952","S2-151782","Rel-10","23.228","10.8.0","OMR","1123","1","F",null,"","","","",""]
["S2-151672","Detailed description for informing about potential network issues","Huawei, HiSilicon, China Mobile, Cisco","Mirko Schramm",23396,"CR","","","Summary of change: It is proposed to document the detailed functional description for informing 3rd party about potential network issues.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12150,"Revised","2015-05-19T07:21:41.913","2015-05-19T13:28:51.713","","S2-151908","Rel-13","23.682","13.1.0","AESE","0116","","B",null,"","","","",""]
["S2-151673","Revision of ePDG selection procedures","Qualcomm Incorporated, Rogers Communications, Deutsche Telekom","Faccin Stefano",60610,"CR","","","Rel-13 mirror CR: Summary of change: The solution for ePDG selection is modified to enable both selection based on static information configured by the HPLMN, and more dynamic selection if the HPLMN does not provide such configuration. In particular, the solution enables more flexibility to the HPLMN to configure when and how the UE shall select the ePDG based on FQDNs provided by the HPLMN versus using FQDNs based on the PLMN ID.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11210,"Available","2015-05-19T07:22:55.110","2015-05-19T07:49:53.020","","","Rel-13","23.402","13.1.0","TEI12","1363","","A",null,"","","","",""]
["S2-151674","Revision of ePDG selection procedures","Qualcomm Incorporated, Rogers Communications, Deutsche Telekom","Faccin Stefano",60610,"CR","","","Summary of change: The solution for ePDG selection is modified to enable both selection based on static information configured by the HPLMN, and more dynamic selection if the HPLMN does not provide such configuration. In particular, the solution enables more flexibility to the HPLMN to configure when and how the UE shall select the ePDG based on FQDNs provided by the HPLMN versus using FQDNs based on the PLMN ID.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11220,"Available","2015-05-19T07:22:55.170","2015-05-19T07:49:53.037","","","Rel-12","23.402","12.8.0","TEI12","1364","","F",null,"","","","",""]
["S2-151675","LS response on static configuration for ePDG selection","Qualcomm Incorporated","Faccin Stefano",60610,"LS out","","","To: CT WG1. Attachments: S2-151673, S2-151674","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11230,"Available","2015-05-19T07:22:55.233","2015-05-19T07:49:53.053","","","Rel-13","","","","","","","","S2-151446","CT WG1"]
["S2-151676","OMR handling of SDP offer-answer exchanges after media path has been selected","Nokia Networks, Ericsson","Martin Oettl",17230,"CR","","","Rel-11 mirror CR: Summary of change: In subsequent SDP offer-answer exchanges, OMR procedures shall not change the media path. Details of those procedures are left for stage 3 work.","16","5.4","IMS-Related Maintenance",10990,"Revised","2015-05-19T07:23:12.037","2015-05-19T07:41:23.940","S2-150953","S2-151783","Rel-11","23.228","11.10.0","OMR","1124","1","A",null,"","","","",""]
["S2-151677","OMR handling of SDP offer-answer exchanges after media path has been selected","Nokia Networks, Ericsson","Martin Oettl",17230,"CR","","","Rel-12 mirror CR: Summary of change: In subsequent SDP offer-answer exchanges, OMR procedures shall not change the media path. Details of those procedures are left for stage 3 work.","16","5.4","IMS-Related Maintenance",11010,"Revised","2015-05-19T07:25:08.320","2015-05-19T07:41:23.970","S2-150954","S2-151784","Rel-12","23.228","12.8.0","OMR","1125","1","A",null,"","","","",""]
["S2-151678","Resource management for background data transfer via Rx","Huawei, HiSilicon, NTT DOCOMO","Mirko Schramm",23396,"CR","","","Summary of change: It is proposed to document the detailed functional description of resource management for background data transfer via Rx.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12350,"Revised","2015-05-19T07:26:13.467","2015-05-19T13:28:51.680","","S2-151941","Rel-13","23.203","13.3.0","AESE","0975","","B",null,"","","","",""]
["S2-151679","OMR handling of SDP offer-answer exchanges after media path has been selected","Nokia Networks, Ericsson","Martin Oettl",17230,"CR","","","Rel-13 mirror CR: Summary of change: In subsequent SDP offer-answer exchanges, OMR procedures shall not change the media path. Details of those procedures are left for stage 3 work.","16","5.4","IMS-Related Maintenance",11030,"Revised","2015-05-19T07:26:57.303","2015-05-19T07:41:24.017","S2-150955","S2-151785","Rel-13","23.228","13.2.0","OMR","1126","1","A",null,"","","","",""]
["S2-151680","Issues with OMR and subsequent SDP offer/answer transactions","Nokia Networks, Ericsson","Martin Oettl",17230,"other","","","Discussion paper on OMR procedures shall not change the media path.","16","5.4","IMS-Related Maintenance",11050,"Noted","2015-05-19T07:29:44.770","2015-05-19T07:40:18.480","","","","","","","","","","","","","","",""]
["S2-151681","Clean up and evaluation/conclusion on issues with one solution","Qualcomm Incorporated","Miguel Griot",43100,"pCR","","","Resolves editor's notes, general clean up and adds evaluation for issues that have only one solution captured in TR. Concludes that these solutions are feasible and target for normative work.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15330,"Revised","2015-05-19T07:30:53.053","2015-05-19T09:04:07.477","","S2-151920","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151682","Evaluation of paging strategy solutions for Idle mode Issue 2","Qualcomm Incorporated","Miguel Griot",43100,"pCR","","","Evaluates paging strategy solutions for idle mode Issue 2, and concludes that it is more efficient that a RAN based solution for determining the paging occasion is more efficient and should be adopted assuming RAN adopts a RAN based approach.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15410,"Revised","2015-05-19T07:30:53.067","2015-05-19T09:04:07.527","","S2-151923","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151683","Update and Evaluation of extended C-DRX issues 2 and 3","Qualcomm Incorporated","Miguel Griot",43100,"pCR","","","Evaluates the different solutions for extended C-DRX issues 2 and 3","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15580,"Revised","2015-05-19T07:30:53.083","2015-05-19T11:01:00.517","","S2-151983","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151684","Overall conclusion","Qualcomm Incorporated","Miguel Griot",43100,"pCR","","","Proposes an overall conclusion of feasibility","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15610,"Revised","2015-05-19T07:30:53.083","2015-05-19T11:01:00.547","","S2-151984","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151685","New Work Item on Extended DRX cycle for Power Consumption Optimization","Qualcomm Incorporated","Miguel Griot",43100,"WID","","","Proposes a work item to capture normative work derived from the study FS_eDRX","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16770,"Revised","2015-05-19T07:30:53.100","2015-05-19T09:04:07.540","","S2-151878","Rel-13","","","","","","","","","","","",""]
["S2-151686","Feasibility of Core Network restart handling with extended DRX","Qualcomm Incorporated, Huawei","Miguel Griot",43100,"other","","","This contribution shows some options for core network restart handling when Idle mode extended DRX is used. Although, Core Network restart is in the realm of CT WG4, and some more optimal/detailed solutions could be adopted in CT WG4, it should be clear that core network restart does not affect the overall feasibility of extended DRX feature.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15710,"Available","2015-05-19T07:30:53.100","2015-05-19T09:04:07.573","","","Rel-13","","","","","","","","","","","",""]
["S2-151687","3GPP Work Item Exception for eDRX","Qualcomm Incorporated","Miguel Griot",43100,"other","","","Work item exception sheet for new proposed WID eDRX","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15670,"Revised","2015-05-19T07:30:53.113","2015-05-19T11:01:00.467","","S2-152055","Rel-13","","","","","","","","","","","",""]
["S2-151688","Cover sheet for FS_eDRX","Qualcomm Incorporated","Miguel Griot",43100,"WI status report","","","Proposed cover sheet for completion of TR 23.770","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15640,"Revised","2015-05-19T07:30:53.130","2015-05-19T11:01:00.483","","S2-151985","Rel-13","","","","","","","","","","","",""]
["S2-151689","Proposal for paging for coverage enhancement","Qualcomm Incorporated","Miguel Griot",43100,"other","","","Proposes a solution for paging to devices using coverage enhancement based on RAN working groups feedback.","39","6.20.1","TEI13 Category B/C for 3GPP Packet Access",16460,"Available","2015-05-19T07:30:53.130","2015-05-19T09:04:07.587","","","Rel-13","","","","","","","","","","","",""]
["S2-151690","Configuring AF application identifier value in PCRF to avoid SRVCC","ZTE","Zhendong Li",38521,"CR","","","Summary of change: If the operator wants to avoid SRVCC in WebRTC, the AF and PCRF should be configured with same specific AF application identifier used in PCC procedure to avoid QCI I bearer establishment.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13330,"Revised","2015-05-19T07:31:50.150","2015-05-19T08:56:20.923","","S2-151851","Rel-13","23.203","13.3.0","eWebRTCi","0976","","B",null,"","","","",""]
["S2-151691","Rel-13 Work Item Exception for MBMS_enh","Nokia Networks","Rainer Liebhart",13470,"other","","","Exception sheet for the new Rel-13 WID on MBMS Enhancements (S2-151658).","34","6.14","MBMS Enhancements (MBMS_enh)",15310,"Revised","2015-05-19T07:35:25.430","2015-05-19T08:14:57.083","","S2-152054","Rel-13","","","","","","","","","","","",""]
["S2-151692","Clarifications to Solution #3 for Key Issue #3","Qualcomm Incorporated","Faccin Stefano",60610,"pCR","","",": the contribution adds clarifications to an existing solution","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15980,"Revised","2015-05-19T07:38:48.997","2015-05-19T07:49:53.083","","S2-151823","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151693","Solution for Key Issue 5: IMS Filtering","Qualcomm Incorporated","Faccin Stefano",60610,"pCR","","","the contribution introduces two-IMS based solutions for key issue 5.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16070,"Merged","2015-05-19T07:38:48.997","2015-05-19T07:49:53.100","","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151694","Discussion on re-use of existing IMS connectivity","Qualcomm Incorporated","Faccin Stefano",60610,"pCR","","","the contribution discusses the issue related to whether a UE that has a regular PDN connection over WLAN and an IMS registration can re-use the existing connectivity for IMS emergency over WLAN.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16130,"Revised","2015-05-19T07:38:49.013","2015-05-19T07:49:53.130","","S2-151836","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151695","New Key Issue: Determination of Emergency Call Support","Qualcomm Incorporated","Faccin Stefano",60610,"pCR","","","the contributions adds a new key issues relating to determining whether an emergency call can be supported for the UE in the current location.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16080,"Revised","2015-05-19T07:38:49.030","2015-05-19T07:49:53.147","","S2-151835","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151696","Solution for key issue on Determination of Emergency Call Support","Qualcomm Incorporated","Faccin Stefano",60610,"pCR","","","the contribution adds a solution for the key issue on Determination of Emergency Call Support.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16120,"Available","2015-05-19T07:38:49.030","2015-05-19T07:49:53.177","","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151697","Welcome to Fukuoka_SA2#109","NTT DOCOMO INC.","Takashi Koshimizu",16997,"other","","","This provides logistics and welcome information to Fukuoka SA WG2#109 meeting from JF3.","0","1","Opening of the meeting",10020,"Revised","2015-05-19T07:39:52.897","2015-05-19T08:43:40.887","","S2-151767","","","","","","","","","","","","",""]
["S2-151698","ePDG Selection Enhancements","Motorola Mobility","Apostolis Salkintzis",22112,"CR","","","Summary of change: The UE may be configured with a list of 'VPLMNs with preferred ePDG selection'. When the UE is roaming to any VPLMN in this list, the UE shall attempt to select first an ePDG in the VPLMN; otherwise the UE shall attempt to select an ePDG in the HPLMN. It is further clarified that the UE may be configured with (a) the FQDN of ePDG in the HPLMN and (b) the FQDNs of ePDGs in various VPLMNs.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11240,"Available","2015-05-19T07:44:45.137","2015-05-19T12:03:29.223","","","Rel-13","23.402","13.1.0","TEI13","1365","","C",null,"","","","",""]
["S2-151699","Resolving FMSS editor's note for solutions 1.1 and 1.2 of key issue #1","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Allot Communications, Cisco","Nicolas Drevon",16459,"pCR","","","This paper intends to solve the editor's note related to the way the SFC Controller receives traffic steering policies when leveraging the ONF work.","33","6.13","Flexible Mobile Service Steering (FMSS)",14890,"Revised","2015-05-19T07:45:10.767","2015-05-19T08:44:37.187","","S2-151938","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151700","Session/bearer release cause over S2b","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Nicolas Drevon",16459,"CR","","","Summary of change: -  An Untrusted WLAN Release cause is introduced over S2b. -  It is clarified that the RAN/NAS Release Cause, TWAN Release Cause and UWAN Release Cause shall be provided (if available) by the PGW to PCRF independently from any event trigger.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11330,"Revised","2015-05-19T08:07:01.403","2015-05-19T08:44:37.217","","S2-151827","Rel-13","23.203","13.3.0","TEI13","0977","","F",null,"","","","",""]
["S2-151701","Possible Solutions for Metadata Transferring","Huawei, HiSilicon","Shufeng Shi",56675,"pCR","","","This contribution proposes several possible solutions for metadata transferring","33","6.13","Flexible Mobile Service Steering (FMSS)",14910,"Revised","2015-05-19T08:09:21.133","2015-05-19T11:49:31.320","","S2-151939","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151702","Supporting Class of Users","Nokia Networks","Martin Oettl",17230,"CR","","","Summary of change: Adding a NOTE which clarifies that the pool of identities granted towards a third party owning the WWSF may also be a wildcarded range of identities.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13260,"Revised","2015-05-19T08:10:55.920","2015-05-19T08:14:16.273","","S2-151849","Rel-13","23.228","13.2.0","eWebRTCi","1134","","B",null,"","","","",""]
["S2-151703","Conclusion on Metadata","Huawei, HiSilicon","Shufeng Shi",56675,"pCR","","","This contribution proposes solution evaluation and conclusion on metadata.","33","6.13","Flexible Mobile Service Steering (FMSS)",15100,"Available","2015-05-19T08:11:34.670","2015-05-19T11:49:45.173","","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151704","Session/bearer release cause over S2b","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Nicolas Drevon",16459,"CR","","","Summary of change: - An Untrusted WLAN Release cause is introduced over S2b. - It is also clarified for S2a and S2b that the PGW also stores the Release Cause in the CDRs (this is missing in the current specification).","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11360,"Revised","2015-05-19T08:11:34.890","2015-05-19T08:44:37.247","","S2-151828","Rel-13","23.402","13.1.0","TEI13","1366","","F",null,"","","","",""]
["S2-151705","Paging optimizations","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Nicolas Drevon",16459,"CR","","","Summary of change: It is specified that the 'information on recommended cells and eNBs for paging' is stored by the MME, and used by the MME to help determining the eNBs to be paged as well as to provide the information on recommended cells to each of these eNBs when paging the UE.","39","6.20.1","TEI13 Category B/C for 3GPP Packet Access",16490,"Available","2015-05-19T08:20:16.980","2015-05-19T08:44:37.280","","","Rel-13","23.401","13.2.0","TEI13","2878","","B",null,"","","","",""]
["S2-151706","Overall_evaluation_on_FMSS_solutions_for_key_issue_#1","China Unicom, Intel, China Telecom, KDDI","Yang Xu",61805,"pCR","","","This paper evaluates the FMSS solutions for key issue #1 from four aspects in 23.718.","33","6.13","Flexible Mobile Service Steering (FMSS)",15080,"Available","2015-05-19T08:33:48.210","2015-05-19T09:04:11.223","","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151707","Alignment of RUCI reporting restrictions' basis for UPCON","China Telecom, ZTE","Jinyan Li",46923,"CR","","","Summary of change: Align the reporting restrictions on per UE per APN basis.","21","6.1.2","Rel-13 PCC/QoS Maintenance",11140,"Revised","2015-05-19T08:37:33.307","2015-05-19T09:21:58.947","","S2-151825","Rel-13","23.203","13.3.0","UPCON","0978","","F",null,"","","","",""]
["S2-151708","Invoking LRF in S2b case","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","Updates solution 8 (LRF) to also cover the S2b case","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16000,"Noted","2015-05-19T08:42:32.667","2015-05-19T13:10:28.900","","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151709","Concluding on the decomposed architecture for WebRTC","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","Proposes a solution and a conclusion on the decomposed architecture for WebRTC","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13100,"Merged","2015-05-19T08:45:15.843","2015-05-19T12:18:42.990","","","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151710","Rel-13 Work Item Exception for eWebRTCi","Alcatel-Lucent","Laurent Thiebaut",11066,"WI status report","","","Rel-13 Work Item Exception for eWebRTCi","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13410,"Revised","2015-05-19T08:51:17.297","2015-05-19T13:47:47.110","","S2-151855","Rel-13","","","","","","","","","","","",""]
["S2-151711","Conclusions for Enhancements to Open ProSe Direct Discovery","Qualcomm Incorporated","Haris Zisimopoulos",41602,"pCR","","","This contribution proposed conclusions for the Enhancements to Open ProSe Direct Discovery.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14180,"Approved","2015-05-19T08:51:25.517","2015-05-19T12:54:11.403","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151712","Rel-13 Work Item Exception for FS_SEW","Alcatel-Lucent","Laurent Thiebaut",11066,"pCR","","","Rel-13 Work Item Exception for FS_SEW","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16280,"Revised","2015-05-19T09:00:43.317","2015-05-19T14:05:14.727","","S2-151843","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151713","Location Info parameter for Direct Discovery (public safety use)","ITRI","Stephan Gleixner",44214,"pCR","","","Proposes to include Location information parameter in Direct Discovery (public safety use) Clause 6.1 for the purpose of proximity estimation.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14150,"Noted","2015-05-19T09:10:35.207","2015-05-19T13:13:59.777","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151714","Adding IP version to content of Connectivity Info for UE-to-Network Relay Discovery","ITRI","Stephan Gleixner",44214,"pCR","","","This contribution discusses the usefulness of adding the IP version of the PDN connection between UE-to-Network Relay and PDN Gateway to the content of the Connectivity Info for UE-to-Network Relay Discovery.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13450,"Available","2015-05-19T09:13:41.597","2015-05-19T13:14:55.313","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151715","Changes to Match Report operation for Restricted Direct Discovery","ITRI","Stephan Gleixner",44214,"pCR","","","This contribution proposes changes to the Match Report operation for Restricted Direct Discovery to ensure that the Monitoring UE receives the metadata when it is available on the ProSe Application Server.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14270,"Withdrawn","2015-05-19T09:15:38.193",null,"","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151716","Correction of specification of Group Call suspension","Vodafone","Maurice Pope",648,"CR","","","Summary of change: Modification of section 5.4 to correct the MBMS suspension mechanism and not to refer to section 5.3.3.3, as the UE should not stop listening to MBMS channels.","13","5.1","3GPP Packet Access Maintenance",10810,"Revised","2015-05-19T09:23:46.743","2015-05-19T11:19:35.363","","S2-151986","Rel-12","23.468","12.4.0","GCSE_LTE-MBMS_CM","0063","","F",null,"","","","",""]
["S2-151717","Correction of specification of Group Call suspension","Vodafone","Maurice Pope",648,"CR","","","Rel-13 mirror CR: Summary of change: Modification of section 5.4 to correct the MBMS suspension mechanism and not to refer to section 5.3.3.3, as the UE should not stop listening to MBMS channels.","13","5.1","3GPP Packet Access Maintenance",10840,"Revised","2015-05-19T09:29:39.263","2015-05-19T11:19:35.317","","S2-151988","Rel-13","23.468","13.0.0","GCSE_LTE-MBMS_CM","0064","","A",null,"","","","",""]
["S2-151718","Rel-13 Work Item Exception for SEW1","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Rel-13 Work Item Exception for SEW1. This is the normative WID spinned-off from the phase 1 of FS_SEW. may have to be moved to AI 7.2.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16300,"Revised","2015-05-19T09:43:58.257","2015-05-19T14:00:57.197","","S2-151844","Rel-13","","","","","","","","","","","",""]
["S2-151719","UE Usage Type clarifications","NEC","Genadi Velev",40661,"CR","","","Summary of change: It is proposed that in case that HPLMN supports DCN, the HPLMN can decide whether to send or not the 'UE Usage Type' parameter to the VPLMN based on various criterias, e.g. if the value is 'operator specific', or if there is a corresponding SLA in place, etc.","25","6.3","Dedicated Core Networks (DECOR)",11610,"Merged","2015-05-19T09:48:51.057","2015-05-19T13:25:05.727","S2-151065","","Rel-13","23.401","13.2.0","DECOR","2855","1","C",null,"","","","",""]
["S2-151720","ETWS/PWS supporting for non-public safety UEs in IOPS network","ZTE","Jinguo Zhu",32987,"pCR","","","This contribution proposes to support ETWS/PWS for non public safety UE in IOPS network","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15780,"Noted","2015-05-19T09:51:09.633","2015-05-19T10:33:06.320","","","Rel-13","23.797","0.1.0","FS_IOPS_St2","","","","","","","","",""]
["S2-151721","Clarification on service authorisation procedure based on location","ZTE, ZTE Mobile","Jinguo Zhu",32987,"CR","","","Summary of change: It is clarfied that the authorisation info provided to the UE applies to the serving PLMN which is obtained from the HSS.","13","5.1","3GPP Packet Access Maintenance",10480,"Revised","2015-05-19T09:51:09.647","2015-05-19T10:33:06.337","","S2-151892","Rel-12","23.303","12.4.0","ProSe","0173","","F",null,"","","","",""]
["S2-151722","Adding ProSe Discovery UE ID in the service authorization","ZTE, ZTE Mobile","Jinguo Zhu",32987,"CR","","","Summary of change: This CR proposes to update the service authorization procedure to add the ProSe Discovery UE ID","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14200,"Revised","2015-05-19T09:51:09.697","2015-05-19T10:33:06.380","","S2-151806","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0174","","B",null,"","","","",""]
["S2-151723","Corrections to OMR-based e2e media transport solution","Orange","Antoine Mouquet",38438,"pCR","","","Corrections to the OMR-based e2e media transport solution, mainly considering that the eP-CSCF does not allocate a TrGW but an IMS-AGW.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13170,"Revised","2015-05-19T09:54:30.813","2015-05-19T12:43:53.883","","S2-152092","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151724","Paging optimization analysis","Huawei, Hisilicon","Runze Zhou",60945,"pCR","","","Analyze the paging optimization and propose more straight forward way.","39","6.20.1","TEI13 Category B/C for 3GPP Packet Access",16470,"Available","2015-05-19T10:42:57.333","2015-05-19T11:10:51.743","","","Rel-13","","","SAES, TEI13","","","","","","","","",""]
["S2-151725","Evaluation and conclusion with updates in Solution 2 Option A","Samsung","Sung Hwan Won",46717,"pCR","","","Solution 2 Option A is modified and solutions are evaluated. According to the evaluation, conclusion is drawn.","34","6.14","MBMS Enhancements (MBMS_enh)",15300,"Available","2015-05-19T10:54:13.780","2015-05-19T11:11:49.823","","","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151726","Conclusion for the decomposed architecture","Huawei","Wanling Ye",47063,"pCR","","","It is proposed to conclude the decomposed architecture as an alternative to solution 3 for the final architecture.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13070,"Revised","2015-05-19T10:59:28.320","2015-05-19T11:13:03.610","","S2-151853","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151727","Service Continuity for ProSe","Huawei, Hisilicon, Ericsson","Runze Zhou",60945,"pCR","","","This contribution proposes a solution for service continuity in which case the UE losing connection reconnects to network via a UE-to-Network Relay and re-enters E-UTRAN coverage from UE-to-Network Relay.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13640,"Noted","2015-05-19T11:25:47.257","2015-05-19T11:29:51.993","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151728","Solution for ProSe Group Priority","Huawei, Hisilicon","Runze Zhou",60945,"pCR","","","This contribution proposes that Public Safety Application Server (e.g. MCPTT Server) is the best place to determine the group priority, thereafter signals that to the Prose Function to achieve network controlled group priority for 1-to-many communication.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13580,"Noted","2015-05-19T11:25:47.257","2015-05-19T11:29:52.023","S2-150823","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151729","Clarification on Group Info","Huawei, Hisilicon","Runze Zhou",60945,"pCR","","","This contribution clarifies the Group Info in the discovery message and proposes some changes.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13830,"Noted","2015-05-19T11:25:47.273","2015-05-19T11:29:52.070","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151730","Discussion on the issues of solution 4","Huawei, Hisilicon","Runze Zhou",60945,"pCR","","","This contribution discusses several issues not handled in solution 4.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14430,"Noted","2015-05-19T11:25:47.273","2015-05-19T11:29:52.103","","","Rel-13","23.709","1.2.0","FS_HLcom","","","","","","","","",""]
["S2-151731","SA WG2 Exception Sheet for MCPTT","U.S. Department of Commerce (SA WG2 MCPTT Rapporteur)","Randy Bloomfield",56665,"other","","","SA WG2 Exception sheet for the MCPTT feature.","24","6.2","Mission Critical Push to Talk over LTE (MCPTT)",11420,"Revised","2015-05-19T11:44:45.917","2015-05-19T13:07:26.123","","S2-152118","Rel-13","","","","","","","","","","","",""]
["S2-151732","Analysis on the direct discovery message size","Samsung","Youngkyo Baek",46395,"pCR","","","This contribution analyzes the size of the direct discovery message size, and based on the analysis it proposes to choose the PC5-D as the discovery message transport.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13720,"Revised","2015-05-19T11:45:57.897","2015-05-19T12:04:10.767","","S2-151772","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151733","conclusion for the direct discovery for public safety use","Samsung","Youngkyo Baek",46395,"pCR","","","In this contribution we propose to solve the remaining issues for ProSe direct discovery for public safety use and conclude the study on the direct discovery except for other WG related work.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13860,"Available","2015-05-19T11:48:58.763","2015-05-19T12:04:10.847","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151734","conclusion for one-to-one communication","Samsung","Youngkyo Baek",46395,"pCR","","","In this contribution we propose to solve the remaining issues for ProSe one-to-one communication and conclude the study phase at least for SA WG2 work scope.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14090,"Revised","2015-05-19T11:50:58.400","2015-05-19T12:04:10.890","","S2-151992","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151735","FFS issues on ProSe UE-Network Relay for eMBMS traffic","Samsung","Youngkyo Baek",46395,"pCR","","","In this contribution we propose to solve the remaining issues on ProSe UE-to-Network relay for eMBMS traffic relay use.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13950,"Noted","2015-05-19T11:54:40.907","2015-05-19T12:04:10.987","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151736","Introduction of monitoring procedures","Huawei, HiSilicon, Intel, Alcatel-Lucent, Cisco, LG Electronics","Frank Mademann",6821,"CR","","","Summary of change: The procedures for supporting monitoring configuration via MME/SGSN and via HSS are introduced. The procedure for reporting of Monitoring Events from the HSS or the MME/SGSN is also introduced.","28","6.6","Monitoring Enhancements (MONTE)",12720,"Revised","2015-05-19T11:56:21.543","2015-05-19T13:27:07.707","S2-151276","S2-151904","Rel-13","23.682","13.1.0","MONTE","0097","3","B",null,"","","","",""]
["S2-151737","conclusion for ProSe UE-Network Relays","Samsung","Youngkyo Baek",46395,"pCR","","","In this contribution we propose to solve the remaining issues for ProSe UE-to-Network relay and conclude the study phase conditionally.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14040,"Revised","2015-05-19T11:56:36.847","2015-05-19T12:04:11.033","","S2-151991","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151738","additional note for Gx solution","KDDI","Takeshi Usui",59388,"pCR","","","This paper proposes an additional note for Gx solution.","33","6.13","Flexible Mobile Service Steering (FMSS)",14940,"Available","2015-05-19T11:58:49.560","2015-05-19T12:06:08.970","S2-151638","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151739","Route MBMS Session Start using SAI derived from TAI. Describe broadcast area with ECGIs.","Vodafone","Chris Pudney",1122,"pCR","","","Describes an additional/complementary solution for simple O&M of group areas for e.g. Public Safety users.","34","6.14","MBMS Enhancements (MBMS_enh)",15250,"Revised","2015-05-19T12:10:44.983","2015-05-19T12:14:25.260","","S2-151916","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151740","SID on VoLTE with S8 Home Routing","NTT DOCOMO","Irfan Ali",50390,"WID","","","Proposes a study item to identify the specification changes needed to enable S8HR as a routing architecture for VoLTE","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10180,"Revised","2015-05-19T12:16:38.250","2015-05-19T13:58:50.587","","S2-151880","Rel-4","","","","","","","","","","","",""]
["S2-151741","[LS OUT] On VoLTE Roaming Architecture","NTT DOCOMO","Motohiro Abe",57779,"LS out","","","Replies to two GSMA LS (S2-151434 and S2-151440) on VoLTE Roaming Architecture. SA WG2 has approved SID on VoLTE with S8HR.","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10230,"Revised","2015-05-19T12:16:38.250","2015-05-19T13:58:50.570","","S2-151974","Rel-4","","","","","","","","S2-151434","TSG SA, TSG CT, GSMA PMSC, GSMA RAG","CT WG3, SA WG3-LI"]
["S2-151742","Per subscriber IMS voice over PS session indicator in HSS for roaming","NTT DOCOMO","Irfan Ali",50390,"CR","","","Summary of change: HPLMN provides a IMS voice over PS session indicator to serving PLMN, to control support of IMS voice in VPLMN on a per subscriber basis. Based on this indication, the MME sets the IMS voice over PS session indicator accordingly.","40","6.20.4","TEI13 Category B/C for IMS, IMS-Related, Emergency, Other",16520,"Revised","2015-05-19T12:16:38.267","2015-05-19T13:58:50.557","","S2-151786","Rel-13","23.401","13.2.0","TEI13","2879","","C",null,"","","","",""]
["S2-151743","Introduce the Dedicated Core Network (DECOR) feature","NTT DOCOMO, Huawei, Ericsson, NEC, Samsung","Irfan Ali",50390,"CR","","","Summary of change: Introduce the decor feature based on conclusions of TR 23.707.","25","6.3","Dedicated Core Networks (DECOR)",11480,"Revised","2015-05-19T12:16:38.390","2015-05-19T13:15:50.523","S2-151372","S2-151788","Rel-13","23.060","13.2.0","DECOR","1953","5","B",null,"","","","",""]
["S2-151744","Clarification on Service Authorization Configurations","NTT DOCOMO, Huawei, Ericsson, NEC, Samsung","Runze Zhou",60945,"pCR","","","In this contribution, we proposed that validity timer of the configurations provisioned in service authorization procedures shall have the same time duration.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14220,"Available","2015-05-19T12:40:43.280","2015-05-19T12:52:09.223","S2-150883","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151745","Restricted ProSe Direct Discovery Model A Using on demand Announcing","Huawei, HiSilicon","Runze Zhou",60945,"CR","","","Summary of change: Adding the introductions and procedure details for Restricted ProSe Direct Discovery with on demand announcement.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14390,"Revised","2015-05-19T12:40:43.297","2015-05-19T12:51:51.127","","S2-151805","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0175","","B",null,"","","","",""]
["S2-151746","Discussion of Network Feature Support for ProSe Discovery and Solution Proposed","Huawei, HiSilicon","Runze Zhou",60945,"pCR","","","solutions are proposed how to avoid unnecessary signalling exchange over PC3 interface between the UE and ProSe Function, in case the network disable its ProSe discovery feature.","13","5.1","3GPP Packet Access Maintenance",10860,"Withdrawn","2015-05-19T12:40:43.390","2015-05-19T12:51:27.710","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151747","Network Feature Support for ProSe Discovery","Huawei, HiSilicon","Runze Zhou",60945,"CR","","","Summary of change: Network can indicate the network capability support for ProSe Discovery to the UE during the Attach and TAU procedure","13","5.1","3GPP Packet Access Maintenance",10570,"Available","2015-05-19T12:40:43.407","2015-05-19T12:51:27.727","","","Rel-12","23.303","12.4.0","ProSe","0176","","F",null,"","","","",""]
["S2-151748","Support of Lawful Interception with the OMR-based e2e media transport solution","Orange","Antoine Mouquet",38438,"pCR","","","Update to the OMR-based e2e media transport solution to comply with the LS reply received from SA WG3-LI (S2-151653).","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13200,"Revised","2015-05-19T12:46:09.997","2015-05-19T12:47:34.613","","S2-151832","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151749","Monitoring via PCRF","Ericsson","Shabnam Sultana",21207,"CR","","","Summary of change: Reporting current user location and communication failure via PCRF as defined in 23.203. Clarifications are included in this version as follows: - A note is added to sub-clause 5.n.x.2 to clarify that the UE IP address is supposed not to be NAT'ed, the reason is that PCC framework is reused as currently defined that places the responsibility to provide the UE IP address known at the PCEF over Rx interface, the SCEF has no capabilities to translate the UE IP address provided in an API to the SCS/AS. - References to the extenal identifier are removed. The reason is that the PCC framework in stage 3 defines that if the UE IP address is provided it is used for session binding in the PCRF. - Communication fauilure is extended to include release codes for untrusted WLAN as well.","28","6.6","Monitoring Enhancements (MONTE)",12860,"Revised","2015-05-19T13:05:36.947","2015-05-19T13:09:45.283","S2-151409","S2-151978","Rel-13","23.682","13.1.0","MONTE","0093","4","B",null,"","","","",""]
["S2-151750","[DRAFT] LS reply on Public Safety discovery","Intel","Saso Stojanovski",24932,"LS out","","","To: SA WG3 Cc: SA WG1, RAN WG1, RAN WG2","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13870,"Available","2015-05-19T13:25:31.173","2015-05-19T13:53:26.960","","","","","","","","","","","S2-151467","SA WG3","SA WG1, RAN WG1, RAN WG2"]
["S2-151751","[DRAFT] LS reply on ProSe Priorities","Intel","Saso Stojanovski",24932,"LS out","","","To: RAN WG2 Cc: SA WG6, RAN WG1, SA WG1","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13590,"Revised","2015-05-19T13:27:09.377","2015-05-19T13:53:26.993","","S2-151775","","","","","","","","","S2-151650","RAN WG2","SA WG6, RAN WG1, SA WG1"]
["S2-151752","On UE-UE Relay work in SA WG2 (ProSe) and SA6 (MCPTT)","Intel","Saso Stojanovski",24932,"other","","","Discusses the status of UE-UE Relay work in SA WG2 (ProSe) and SA WG6 (MCPTT). The objective is to point to possible discrepancies between the work on ProSe UE-UE relays in SA WG2 and MCPTT UE-UE Relays in SA WG6.","24","6.2","Mission Critical Push to Talk over LTE (MCPTT)",11410,"Available","2015-05-19T13:28:45.457","2015-05-19T13:53:27.007","","","","","","","","","","","","","","",""]
["S2-151753","Group message delivery function and procedure","KPN","Toon Norp",8605,"CR","","","Summary of change: High level description for group messge delivery function and delivery procedures is specified. Rev4: Add option to add requested location input to broadcast message and add option to add randomization of the response time information.","29","6.7","Group based Enhancements (GROUPE)",13030,"Revised","2015-05-19T13:29:15.987","2015-05-19T13:56:14.227","S2-151414","S2-151885","Rel-13","23.682","13.1.0","GROUPE","0094","4","B",null,"","","","",""]
["S2-151754","Clarification on use cases for Public Safety Discovery","Intel","Saso Stojanovski",24932,"pCR","","","Clarification on the notion of affiliation among users performing Public Safety Discovery.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13840,"Noted","2015-05-19T13:30:20.180","2015-05-19T13:53:27.040","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151755","Resolution of Editor's note in clause 7.2.2.4","Intel Mobile Communications","Saso Stojanovski",24932,"pCR","","","Proposes a resolution of the Editor's note in clause 7.2.2.4 (Multicast/Broadcast traffic support using IP Multicast on Relay). This is mostly a resubmission of S2-151073.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14020,"Revised","2015-05-19T13:32:06.153","2015-05-19T13:53:27.053","S2-151073","S2-151798","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151756","Closing Editor's notes and FFS items on one-to-one ProSe Direct Communication","Intel","Saso Stojanovski",24932,"pCR","","","Proposes to close several Editor's notes and FFS items on One-to-one ProSe Direct Communication. It also proposes to add layer-2 link maintenance and release functionality in the PC5 Signalling Protocol.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14060,"Revised","2015-05-19T13:33:26.900","2015-05-19T13:53:27.087","","S2-151795","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151757","Addition of group message delivery","KPN, TNO","Toon Norp",8605,"CR","","","A short text is added to reference group based message delivery.","29","6.7","Group based Enhancements (GROUPE)",13060,"Noted","2015-05-19T13:34:43.623","2015-05-20T19:48:51.600","","","Rel-13","23.401","13.2.0","GROUPE","2880","","B",null,"","","","",""]
["S2-151758","Remote UE visibility at the EPC","Intel","Saso Stojanovski",24932,"pCR","","","Proposes to close the FFS item on Remote UE visibility at the EPC","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13960,"Noted","2015-05-19T13:34:45.697","2015-05-19T13:53:26.897","","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151759","Stateful ProSe UE-to-UE Relay","Intel","Saso Stojanovski",24932,"pCR","","","Proposes input to clause 7.3. (Solution for ProSe UE-UE Relays (stateful relay selection)) that is currently almost empty. This is a resubmission of S2-151058 with changes addressing comments in the SA WG2#108 meeting.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14190,"Available","2015-05-19T13:36:40.577","2015-05-19T13:53:26.913","S2-151058","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151760","Well-known identifier for ProSe Broadcast Communication","Intel","Saso Stojanovski",24932,"CR","","","Summary of change: It is clarified that there is a well-known broadcast identifier ProSe Layer-2 Broadcast ID defined as 'all ones'. A broadcast IPv4 or IPv6 address is used as the ProSe Group IP multicast address and there is no security related content.","13","5.1","3GPP Packet Access Maintenance",10680,"Noted","2015-05-19T13:39:44.300","2015-05-19T13:53:26.947","","","Rel-12","23.303","12.4.0","ProSe","0177","","F",null,"","","","",""]
["S2-151761","Two topics related to WLAN interworking","Intel","Saso Stojanovski",24932,"other","","","Discusses two WLAN-interworking related topics: 1) the applicability of RAN rules for RAN-assisted WLAN interworking in Idle mode, and 2) the use of Local Operating Environment (LOE) information for MAPCON.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11350,"Noted","2015-05-19T13:43:42.717","2015-05-19T13:49:03.287","","","","","","","","","","","","","","",""]
["S2-151762","Solution for paging coordination between CN and UE","Intel","Saso Stojanovski",24932,"pCR","","","Proposes a solution for paging coordination between CN and UE","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15400,"Merged","2015-05-19T13:45:26.723","2015-05-19T13:47:42.617","","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151763","Study on VoLTE with S8 Home Routing","NTT DOCOMO","Irfan Ali",50390,"TS or TR","","","TR outline for Study on VoLTE with S8 Home Routing","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10260,"Noted","2015-05-19T13:46:05.990","2015-05-19T13:58:50.617","","","Rel-14","23.401","13.2.0","","","","","","","","","",""]
["S2-151764","Location Based ePDG Selection","Rogers Communications, China Mobile, Intel, Qualcomm Inc.","Alexander Markman",35093,"CR","","","Summary of change: Including Tracking/Location Area Identity information into ePDG FQDN enables selecting ePDG geographically or topologically close to the UE, which in turn enables optimal P-GW selection for the connection.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11280,"Noted","2015-05-19T14:04:02.200","2015-05-19T14:07:16.407","","","Rel-12","23.402","12.8.0","TEI12","1367","","F",null,"","","","",""]
["S2-151765","Discussion of Network Feature Support for ProSe Discovery and Solution Proposed","Huawei, HiSilicon","Runze Zhou",60945,"other","","","Solutions are proposed how to avoid unnecessary signalling exchange over PC3 interface between the UE and ProSe Function, in case the network disable its ProSe discovery feature.","13","5.1","3GPP Packet Access Maintenance",10520,"Noted","2015-05-20T05:51:38.267","2015-05-20T05:54:49.057","","","Rel-12","","","","","","","","","","","",""]
["S2-151766","Conclusion on Service continuity between Network and ProSe UE-to-Network relays","Alcatel-Lucent, Intel, BlackBerry, Deutsche Telekom, Samsung, Nokia Networks","Alessio Casati",13542,"other","","","This contribution attempts to conclude on the topic of Service continuity between Network and ProSe UE-to-Network relays","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13460,"Available","2015-05-20T09:35:42.443","2015-05-20T09:40:26.657","","","Rel-13","","","","","","","","","","","",""]
["S2-151767","Welcome to Fukuoka_SA2#109","NTT DOCOMO INC.","Takashi Koshimizu",16997,"other","","","This provides logistics and welcome information to Fukuoka SA WG2#109 meeting from JF3.","0","1","Opening of the meeting",10030,"Noted","2015-05-20T09:57:11.113","2015-05-20T11:25:29.423","S2-151697","","","","","","","","","","","","","",""]
["S2-151768","Analysis of ePDG selection proposals","BlackBerry UK Limited","Adrian Buckley",26735,"other","","","Discussion of Blackberry concerns with S2-151659, S2-151673 and S2-151698 on ePDG selection.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11250,"Available","2015-05-22T06:07:42.903","2015-06-02T09:43:38.717","","","","","","","","","","","","","","",""]
["S2-151769","Setting up an AS session with required QoS","Intel","Puneet Jain",36283,"CR","","","This provides description of setting up an AS session with required QoS.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12300,"Revised","2015-05-22T06:22:04.033","2015-05-22T14:31:13.817","","S2-151913","Rel-13","23.682","13.1.0","AESE","0117","","B",null,"","","","",""]
["S2-151770","Change the chargeable party at the session set-up or during the session","Intel","Puneet Jain",36283,"CR","","","This provides description of change the chargeable party at the session set-up or during the session","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12450,"Revised","2015-05-22T06:23:51.550","2015-05-22T18:54:26.070","","S2-151942","Rel-13","23.682","13.1.0","AESE","0118","","B",null,"","","","",""]
["S2-151771","Support of Service Continuity for Public Safety","Deutsche Telekom, Alcatel Lucent, Intel, BlackBerry, Samsung, Nokia Networks","Michele Zarri",20505,"pCR","","","This contribution proposes to document in TR 23.713 that IP service continuity for ProSe Public Safety will not be specified in Release 13","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13660,"Noted","2015-06-02T14:10:19.287","2015-06-02T15:16:23.873","S2-151616","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151772","Analysis on the direct discovery message size","Samsung","Youngkyo Baek",46395,"pCR","","","This contribution analyzes the size of the direct discovery message size, and based on the analysis it proposes to choose the PC5-D as the discovery message transport.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13750,"Noted","2015-06-02T14:10:19.300","2015-06-02T15:16:24.763","S2-151732","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151773","On Public Safety discovery message transport","Qualcomm Incorporated, ZTE, U.S. Department of Commerce, Alcatel Lucent","Haris Zisimopoulos",41602,"pCR","","","This paper calculates the estimated discovery message for public safety discovery and proposes to use PC5-D discovery for ProSe UE-Network Relay and Group Member Discovery.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13730,"Revised","2015-06-02T14:10:19.317","2015-06-02T15:16:25.650","S2-151474","S2-151811","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151774","ProSe Priority","Qualcomm Incorporated, Alcatel-Lucent, Intel, U.S. Department of Commerce, LG Electronics","Haris Zisimopoulos",41602,"pCR","","","Discusses options for ProSe Priority and QoS and proposes text for TR 23.713.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13540,"Revised","2015-06-02T14:10:19.333","2015-06-02T15:16:26.527","S2-151573","S2-151779","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151775","[DRAFT] LS reply on ProSe Priorities","SA WG2","Saso Stojanovski",24932,"LS out","","","To: RAN WG2 Cc: SA WG6, RAN WG1, SA WG1","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13600,"Revised","2015-06-02T14:10:19.347","2015-06-02T15:16:27.413","S2-151751","S2-151776","","","","","","","","","S2-151650","RAN WG2","SA WG6, RAN WG1, SA WG1"]
["S2-151776","[DRAFT] LS reply on ProSe Priorities","SA WG2","Saso Stojanovski",24932,"LS out","","","To: RAN WG2, SA WG1, SA WG6. CC: RAN WG1","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13610,"Revised","2015-06-02T14:15:42.413","2015-06-02T15:16:27.430","S2-151775","S2-151807","","","","","","","","","S2-151650","RAN WG2, SA WG1, SA WG6,","RAN WG1"]
["S2-151777","On Prose UE-to-Network Relay discovery","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Qualcomm Incorporated.","Alessio Casati",13542,"pCR","","","This paper focuses on the discovery of a relay suitable to offer a desired connectivity.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13780,"Revised","2015-06-02T14:15:42.443","2015-06-02T15:16:27.447","S2-151656","S2-151812","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151778","[DRAFT] LS reply on Public Safety discovery","SA WG2","Hong Cheng",25668,"LS out","","","To: SA WG3. CC: SA WG1, RAN WG1, RAN WG2","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13800,"Revised","2015-06-02T14:15:42.460","2015-06-02T15:16:28.337","","S2-151813","Rel-13","","","","","","","","S2-151467","SA WG3","SA WG1, RAN WG1, RAN WG2"]
["S2-151779","ProSe Priority","Qualcomm Incorporated, Alcatel-Lucent, Intel, U.S. Department of Commerce, LG Electronics","Haris Zisimopoulos",41602,"pCR","","","Discusses options for ProSe Priority and QoS and proposes text for TR 23.713.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13550,"Revised","2015-06-02T14:15:42.460","2015-06-02T15:16:28.350","S2-151774","S2-151809","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151780","Enhanced MSC Server announcement during Session Transfer","Ericsson","Shabnam Sultana",21207,"CR","","","Summary of change: Remove the list to avoid missing cases","16","5.4","IMS-Related Maintenance",10930,"Agreed","2015-06-02T14:15:42.490","2015-06-02T15:16:29.350","S2-151473","","Rel-12","23.237","12.8.0","vSRVCC, TEI12","0483","1","F","SP-150230","","","","",""]
["S2-151781","Clarification of CS user plane restoration during SRVCC HO","Huawei, HiSilicon, Intel, China Unicom","Runze Zhou",60945,"CR","","","Summary of change: Clarify in TS 23.216 that CS user plane can be resumed once the MSC receives Handover Detection message.","16","5.4","IMS-Related Maintenance",10960,"Agreed","2015-06-02T14:15:42.677","2015-06-02T15:16:31.097","S2-151547","","Rel-12","23.216","12.2.0","SAES-SRVCC, TEI12","0331","2","F","SP-150230","","","","",""]
["S2-151782","OMR handling of SDP offer-answer exchanges after media path has been selected","Nokia Networks, Ericsson","Martin Oettl",17230,"CR","","","Summary of change: In subsequent SDP offer-answer exchanges, OMR procedures shall not change the media path. Details of those procedures are left for stage 3 work.","16","5.4","IMS-Related Maintenance",10980,"Agreed","2015-06-02T14:15:42.850","2015-06-02T15:16:32.093","S2-151671","","Rel-10","23.228","10.8.0","OMR","1123","2","F","SP-150222","","","","",""]
["S2-151783","OMR handling of SDP offer-answer exchanges after media path has been selected","Nokia Networks, Ericsson","Martin Oettl",17230,"CR","","","Rel-11 mirror CR: Summary of change: In subsequent SDP offer-answer exchanges, OMR procedures shall not change the media path. Details of those procedures are left for stage 3 work.","16","5.4","IMS-Related Maintenance",11000,"Agreed","2015-06-02T14:15:43.007","2015-06-02T15:16:33.077","S2-151676","","Rel-11","23.228","11.10.0","OMR","1124","2","A","SP-150222","","","","",""]
["S2-151784","OMR handling of SDP offer-answer exchanges after media path has been selected","Nokia Networks, Ericsson","Martin Oettl",17230,"CR","","","Rel-12 mirror CR: Summary of change: In subsequent SDP offer-answer exchanges, OMR procedures shall not change the media path. Details of those procedures are left for stage 3 work.","16","5.4","IMS-Related Maintenance",11020,"Agreed","2015-06-02T14:15:43.160","2015-06-02T15:16:34.077","S2-151677","","Rel-12","23.228","12.8.0","OMR","1125","2","A","SP-150222","","","","",""]
["S2-151785","OMR handling of SDP offer-answer exchanges after media path has been selected","Nokia Networks, Ericsson","Martin Oettl",17230,"CR","","","Rel-13 mirror CR: Summary of change: In subsequent SDP offer-answer exchanges, OMR procedures shall not change the media path. Details of those procedures are left for stage 3 work.","16","5.4","IMS-Related Maintenance",11040,"Agreed","2015-06-02T14:15:43.333","2015-06-02T15:16:35.090","S2-151679","","Rel-13","23.228","13.2.0","OMR","1126","2","A","SP-150222","","","","",""]
["S2-151786","Per subscriber IMS voice over PS session indicator in HSS for roaming","NTT DOCOMO","Irfan Ali",50390,"CR","","","Summary of change: HPLMN provides a IMS voice over PS session indicator to serving PLMN, to control support of IMS voice in VPLMN on a per subscriber basis. Based on this indication, the MME sets the IMS voice over PS session indicator accordingly.","40","6.20.4","TEI13 Category B/C for IMS, IMS-Related, Emergency, Other",16530,"Withdrawn","2015-06-02T14:15:43.503",null,"S2-151742","","Rel-13","23.401","13.2.0","TEI13","2879","1","C",null,"","","","",""]
["S2-151787","Introduce the Dedicated Core Network (DECOR) feature","NTT DOCOMO, Huawei, Ericsson, NEC, Samsung","Irfan Ali",50390,"CR","","","Summary of change: Introduce the decor feature based on conclusions of TR 23.707","25","6.3","Dedicated Core Networks (DECOR)",11450,"Revised","2015-06-02T14:15:43.677","2015-06-02T15:16:37.070","S2-151539","S2-151817","Rel-13","23.401","13.2.0","DECOR","2837","9","B",null,"","","","",""]
["S2-151788","Introduce the Dedicated Core Network (DECOR) feature","NTT DOCOMO, Huawei, Ericsson, NEC, Samsung","Irfan Ali",50390,"CR","","","Summary of change: Introduce the decor feature based on conclusions of TR 23.707.","25","6.3","Dedicated Core Networks (DECOR)",11490,"Revised","2015-06-02T14:15:43.830","2015-06-02T15:16:38.037","S2-151743","S2-151818","Rel-13","23.060","13.2.0","DECOR","1953","6","B",null,"","","","",""]
["S2-151789","Adding support for load re-balancing within DCN","Ericsson, TeliaSonera, AT&T","Shabnam Sultana",21207,"CR","","","Summary of change: Describes load re-balancing using the NAS Message Redirection procedure within a DCN for E-UTRAN.","25","6.3","Dedicated Core Networks (DECOR)",11540,"Revised","2015-06-02T14:15:44.003","2015-06-02T15:16:39.037","S2-151500","S2-151819","Rel-13","23.401","13.2.0","DECOR","2864","1","B",null,"","","","",""]
["S2-151790","Load re-balancing for SGSNs with Dedicated Core Networks","NTT DOCOMO, Huawei","Irfan Ali",50390,"CR","","","Summary of change: Capture the solution for load balancing and load re-balancing for SGSNs when DCNs are used","25","6.3","Dedicated Core Networks (DECOR)",11590,"Revised","2015-06-02T14:15:44.190","2015-06-02T15:16:40.050","S2-151541","S2-151820","Rel-13","23.236","12.0.0","DECOR","0053","1","B",null,"","","","",""]
["S2-151791","WID update on DECOR","NTT DOCOMO","Irfan Ali",50390,"WID","","","Update plenary meeting number for approval","25","6.3","Dedicated Core Networks (DECOR)",11640,"Approved","2015-06-02T14:15:44.347","2015-06-02T15:16:40.957","S2-151542","","Rel-13","","","","","","","","","","","",""]
["S2-151792","[DRAFT] Request for specification of Dedicated Core Network (DECOR) feature","SA WG2","Daisuke Fujishima",58629,"LS out","","","Ask CT WG4 and RAN WG3 to initiate the specification of DECOR feature.","25","6.3","Dedicated Core Networks (DECOR)",11660,"Revised","2015-06-02T14:15:44.363","2015-06-02T15:16:40.970","S2-151543","S2-151997","Rel-13","","","","","","","",null,"CT WG4, RAN WG3","TSG RAN"]
["S2-151793","eMBMS traffic relay enhancement","Huawei, Hisilicon","Runze Zhou",60945,"pCR","","","In the existing eMBMS traffic relay solution, when the Remote UE sends a TMGI Monitoring Request to the UE-to-Network Relay, actually the Remote UE cannot know whether the TMGI corresponding eMBMS traffic can be transferred by the UE-to-Network Relay. In this contribution, an enhancement step is proposed to make sure the remote UE can always find the right UE-to-Network Relay to transfer the interested eMBMS traffic for him.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13890,"Approved","2015-06-02T14:15:44.377","2015-06-02T15:16:41.003","S2-151568","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151794","TMGI and ECGI advertisement","Qualcomm Incorporated, Alcatel Lucent","Haris Zisimopoulos",41602,"pCR","","","This paper proposes to use PC5-D discovery for ProSe UE-Network Relay TMGI and ECGI advertisement.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13920,"Revised","2015-06-02T14:15:44.393","2015-06-02T15:16:41.890","S2-151476","S2-151814","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151795","Closing Editor's notes and FFS items on one-to-one ProSe Direct Communication","Intel","Saso Stojanovski",24932,"pCR","","","Proposes to close several Editor's notes and FFS items on One-to-one ProSe Direct Communication. It also proposes to add layer-2 link maintenance and release functionality in the PC5 Signalling Protocol.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14070,"Revised","2015-06-02T14:15:44.423","2015-06-02T15:16:42.813","S2-151756","S2-151815","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151796","UE-to-Network Relay release procedure","LG Electronics","Laeyoung Kim",40613,"pCR","","","This P-CR proposes UE-to-Network Relay release procedure.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13980,"Approved","2015-06-02T14:15:44.440","2015-06-02T15:16:43.700","S2-151613","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151797","UE-to-Network Relay selection and connection establishment","Qualcomm Incorporated","Haris Zisimopoulos",41602,"pCR","","","This contribution proposed the principles for the UE-to-Network Relay selection for ProSe.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14000,"Revised","2015-06-02T14:15:44.470","2015-06-02T15:16:44.590","S2-151580","S2-152003","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151798","Resolution of Editor's note in clause 7.2.2.4","Intel Mobile Communications","Saso Stojanovski",24932,"pCR","","","Proposes a resolution of the Editor's note in clause 7.2.2.4 (Multicast/Broadcast traffic support using IP Multicast on Relay). This is mostly a resubmission of S2-151073.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14030,"Approved","2015-06-02T14:15:44.487","2015-06-02T15:16:45.463","S2-151755","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151799","Authorization for broadcasting and use of location information over PC5 for restricted discovery","InterDigital","Mahmoud Watfa",41881,"pCR","","","This document ensures a user is authorized to include location information in PC5 discovery message when announcing, and a user is authorized to use location information in PC5 discovery message when monitoring - both for restricted direct discovery.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14130,"Approved","2015-06-02T14:15:44.503","2015-06-02T15:16:46.353","S2-151512","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151800","Removal of editor's note and Conclusion on Dynamic Metadata","Huawei, Hisilicon","Runze Zhou",60945,"pCR","","","This contribution removes the editor's note and proposes the conclusion on dynamic metadata for open ProSe Direct Discovery enhancement.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14170,"Approved","2015-06-02T14:15:44.517","2015-06-02T15:16:47.227","S2-151567","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151801","Restricted ProSe Direct Discovery Model A procedures","Qualcomm Incorporated, ZTE, Telecom Italia","Haris Zisimopoulos",41602,"CR","","","Summary of change: Adding the introductions and procedure details for restricted ProSe Direct Discovery Model A procedures.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14290,"Revised","2015-06-02T14:15:44.550","2015-06-02T15:16:48.227","S2-151574","S2-152001","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0168","1","B",null,"","","","",""]
["S2-151802","Restricted ProSe Direct Discovery Model B procedures","InterDigital, Qualcomm Incorporated, Telecom Italia, ZTE","Mahmoud Watfa",41881,"CR","","","Summary of change: Adding the introductions and procedure details for Restricted ProSe Direct Discovery Model B procedures.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14320,"Agreed","2015-06-02T14:15:44.707","2015-06-02T15:16:49.223","S2-151511","","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0164","1","B","SP-150233","","","","",""]
["S2-151803","Authorization information for ProSe Restricted Direct Discovery, Model A and B","Telecom Italia, Qualcomm Incorporated","Mario Madella",23765,"CR","","","Summary of change: Adding information to be provisioned to the UE for ProSe Restricted Direct Discovery authorisation and related subscription information.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14340,"Agreed","2015-06-02T14:15:44.893","2015-06-02T15:16:50.237","S2-151558","","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0166","1","B","SP-150233","","","","",""]
["S2-151804","Restricted ProSe Direct Discovery with Application-controlled extension","Qualcomm Incorporated, Interdigital, Telecom Italia","Haris Zisimopoulos",41602,"CR","","","Summary of change: Adding details for restricted ProSe Direct Discovery with application-controlled extension procedures.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14370,"Revised","2015-06-02T14:15:45.063","2015-06-02T15:16:51.207","S2-151577","S2-151816","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0169","1","B",null,"","","","",""]
["S2-151805","Restricted ProSe Direct Discovery Model A Using on demand Announcing","Huawei, HiSilicon","Runze Zhou",60945,"CR","","","Summary of change: Adding the introductions and procedure details for Restricted ProSe Direct Discovery with on demand announcement.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14400,"Revised","2015-06-02T14:15:45.237","2015-06-02T15:16:52.220","S2-151745","S2-152002","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0175","1","B",null,"","","","",""]
["S2-151806","Adding ProSe Discovery UE ID in the service authorization","ZTE, ZTE Mobile","Jinguo Zhu",32987,"CR","","","Summary of change: This CR proposes to update the service authorization procedure to add the ProSe Discovery UE ID","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14210,"Agreed","2015-06-02T14:20:54.150","2015-06-02T15:16:53.217","S2-151722","","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0174","1","B","SP-150233","","","","",""]
["S2-151807","[DRAFT] LS reply on ProSe Priorities","SA WG2","Saso Stojanovski",24932,"LS out","","","To: RAN WG2, SA WG1, SA WG6. CC: RAN WG1","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13620,"Revised","2015-06-02T14:20:54.307","2015-06-02T15:16:54.107","S2-151776","S2-151810","","","","","","","","","S2-151650","RAN WG2, SA WG1, SA WG6,","RAN WG1"]
["S2-151808","Work Item Exception for ProSe","Qualcomm Incorporated (Rapporteur)","Haris Zisimopoulos",41602,"other","","","Exception sheet for eProSe-EXT","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13480,"Revised","2015-06-02T14:26:35.110","2015-06-02T15:16:54.107","S2-151575","S2-151998","Rel-13","","","","","","","","","","","",""]
["S2-151809","ProSe Priority","Qualcomm Incorporated, Alcatel-Lucent, Intel, U.S. Department of Commerce, LG Electronics","Haris Zisimopoulos",41602,"pCR","","","Discusses options for ProSe Priority and QoS and proposes text for TR 23.713.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13560,"Approved","2015-06-02T14:26:35.123","2015-06-02T15:16:54.123","S2-151779","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151810","LS reply on ProSe Priorities","SA WG2","Saso Stojanovski",24932,"LS out","","","To: RAN WG2, SA WG1, SA WG6. CC: RAN WG1","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13630,"Approved","2015-06-02T14:26:35.140","2015-06-02T15:16:55.043","S2-151807","","","","","","","","","","S2-151650","RAN WG2, SA WG1, SA WG6","RAN WG1"]
["S2-151811","On Public Safety discovery message transport","Qualcomm Incorporated, ZTE, U.S. Department of Commerce, Alcatel Lucent","Haris Zisimopoulos",41602,"pCR","","","This paper calculates the estimated discovery message for public safety discovery and proposes to use PC5-D discovery for ProSe UE-Network Relay and Group Member Discovery.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13740,"Approved","2015-06-02T14:26:35.157","2015-06-02T15:16:55.057","S2-151773","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151812","On Prose UE-to-Network Relay discovery","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Qualcomm Incorporated.","Alessio Casati",13542,"pCR","","","This paper focuses on the discovery of a relay suitable to offer a desired connectivity.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13790,"Approved","2015-06-02T14:26:35.170","2015-06-02T15:16:55.963","S2-151777","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151813","LS reply on Public Safety discovery","SA WG2","Hong Cheng",25668,"LS out","","","To: SA WG3. CC: SA WG1, RAN WG1, RAN WG2","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13810,"Approved","2015-06-02T14:26:35.187","2015-06-02T15:16:56.853","S2-151778","","Rel-13","","","","","","","","S2-151467","SA WG3","SA WG1, RAN WG1, RAN WG2"]
["S2-151814","TMGI and ECGI advertisement","Qualcomm Incorporated, Alcatel Lucent","Haris Zisimopoulos",41602,"pCR","","","This paper proposes to use PC5-D discovery for ProSe UE-Network Relay TMGI and ECGI advertisement.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13930,"Revised","2015-06-02T14:26:35.203","2015-06-02T15:16:56.867","S2-151794","S2-151999","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151815","Closing Editor's notes and FFS items on one-to-one ProSe Direct Communication","Intel","Saso Stojanovski",24932,"pCR","","","Proposes to close several Editor's notes and FFS items on One-to-one ProSe Direct Communication. It also proposes to add layer-2 link maintenance and release functionality in the PC5 Signalling Protocol.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14080,"Approved","2015-06-02T14:26:35.217","2015-06-02T15:16:57.773","S2-151795","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151816","Restricted ProSe Direct Discovery with Application-controlled extension","Qualcomm Incorporated, Interdigital, Telecom Italia","Haris Zisimopoulos",41602,"CR","","","Summary of change: Adding details for restricted ProSe Direct Discovery with application-controlled extension procedures.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14380,"Agreed","2015-06-02T14:26:35.233","2015-06-02T15:16:58.770","S2-151804","","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0169","2","B","SP-150233","","","","",""]
["S2-151817","Introduce the Dedicated Core Network (DECOR) feature","NTT DOCOMO, Huawei, Ericsson, NEC, Samsung","Irfan Ali",50390,"CR","","","Summary of change: Introduce the decor feature based on conclusions of TR 23.707","25","6.3","Dedicated Core Networks (DECOR)",11460,"Revised","2015-06-02T14:26:35.407","2015-06-02T15:16:59.753","S2-151787","S2-152107","Rel-13","23.401","13.2.0","DECOR","2837","10","B",null,"","","","",""]
["S2-151818","Introduce the Dedicated Core Network (DECOR) feature","NTT DOCOMO, Huawei, Ericsson, NEC, Samsung","Irfan Ali",50390,"CR","","","Summary of change: Introduce the decor feature based on conclusions of TR 23.707.","25","6.3","Dedicated Core Networks (DECOR)",11500,"Agreed","2015-06-02T14:26:35.577","2015-06-02T15:17:00.753","S2-151788","","Rel-13","23.060","13.2.0","DECOR","1953","7","B","SP-150234","","","","",""]
["S2-151819","Adding support for load re-balancing within DCN","Ericsson, TeliaSonera, AT&T","Shabnam Sultana",21207,"CR","","","Summary of change: Describes load re-balancing using the NAS Message Redirection procedure within a DCN for E-UTRAN.","25","6.3","Dedicated Core Networks (DECOR)",11550,"Revised","2015-06-02T14:26:35.733","2015-06-02T15:17:01.780","S2-151789","S2-152108","Rel-13","23.401","13.2.0","DECOR","2864","2","B",null,"","","","",""]
["S2-151820","Load re-balancing for SGSNs with Dedicated Core Networks","NTT DOCOMO, Huawei, Ericsson, TeliaSonera, AT&T","Irfan Ali",50390,"CR","","","Summary of change: Capture the solution for load balancing and load re-balancing for SGSNs when DCNs are used","25","6.3","Dedicated Core Networks (DECOR)",11600,"Agreed","2015-06-02T14:26:35.890","2015-06-02T15:17:02.780","S2-151790","","Rel-13","23.236","12.0.0","DECOR","0053","2","B","SP-150234","","","","",""]
["S2-151821","Clarification of Key Issue 1 on ePDG Selection for Emergency Services","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution includes clarification to key issue 1","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15890,"Approved","2015-06-02T14:26:36.047","2015-06-02T15:17:03.687","S2-151469","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151822","Base Solution for Key issue 3: Handling of UE multiple provided Location Information","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution proposes solution to the key issue # 6 to distinguish multiple UE provided location and access information","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15950,"Revised","2015-06-02T14:26:36.060","2015-06-02T15:17:04.557","S2-151472","S2-151858","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151823","Clarifications to Solution #3 for Key Issue #3","Qualcomm Incorporated","Faccin Stefano",60610,"pCR","","",": the contribution adds clarifications to an existing solution","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15990,"Approved","2015-06-02T14:26:36.077","2015-06-02T15:17:05.447","S2-151692","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151824","Utilizing WLAN Information for Emergency Services","Motorola Mobility","Apostolis Salkintzis",22112,"pCR","","","Discusses the information provided by WLANs related to emergency services and proposes how this information may be used by the UE. Solutions are proposed for location determination, emergency call number retrieval and WLAN selection.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16020,"Revised","2015-06-02T14:26:36.107","2015-06-02T15:17:06.320","S2-151598","S2-151859","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151825","Alignment of RUCI reporting restrictions' basis for UPCON","China Telecom, ZTE","Jinyan Li",46923,"CR","","","Summary of change: Align the reporting restrictions on per UE per APN basis.","21","6.1.2","Rel-13 PCC/QoS Maintenance",11150,"Revised","2015-06-02T14:26:36.123","2015-06-02T15:17:07.337","S2-151707","S2-151959","Rel-13","23.203","13.3.0","TEI13","0978","1","F",null,"","","","",""]
["S2-151826","[DRAFT] Reply LS on APN Usage in NSWO Rules","SA WG2","Stefano Faccin",42400,"LS out","","","To: CT WG1","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11310,"Revised","2015-06-02T14:26:36.293","2015-06-02T15:17:08.193","","S2-152082","","","","","","","","","S2-151447","CT WG1"]
["S2-151827","Session/bearer release cause over S2b","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Nicolas Drevon",16459,"CR","","","Summary of change: -  An Untrusted WLAN Release cause is introduced over S2b. -  It is clarified that the RAN/NAS Release Cause, TWAN Release Cause and UWAN Release Cause shall be provided (if available) by the PGW to PCRF independently from any event trigger.","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11340,"Agreed","2015-06-02T14:26:36.310","2015-06-02T15:17:08.317","S2-151700","","Rel-13","23.203","13.3.0","TEI13","0977","1","F","SP-150239","","","","",""]
["S2-151828","Session/bearer release cause over S2b","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Nicolas Drevon",16459,"CR","","","Summary of change: - An Untrusted WLAN Release cause is introduced over S2b. - It is also clarified for S2a and S2b that the PGW also stores the Release Cause in the CDRs (this is missing in the current specification).","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11370,"Revised","2015-06-02T14:26:36.450","2015-06-02T15:17:09.300","S2-151704","S2-152083","Rel-13","23.402","13.1.0","TEI13","1366","1","F",null,"","","","",""]
["S2-151829","[DRAFT] Reply to LS from SA WG4: Reply LS on TR 26.924 Study on improved end-to-end QoS handling","SA WG2","Belen Pancorbo",4022,"LS out","","","To: SA WG4. CC: CT WG1, CT WG3, CT WG4","21","6.1.2","Rel-13 PCC/QoS Maintenance",11090,"Revised","2015-06-02T14:26:36.623","2015-06-02T15:17:10.207","","S2-151957","Rel-13","","","","","","","","S2-151654","SA WG4","CT WG1, CT WG3, CT WG4"]
["S2-151830","Concluding on the Solution 7.2.1: WebRTC related IMS service control","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","Updates the solution 7.2.1and proposes a conclusion on the support of WebRTC related IMS service control","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13120,"Revised","2015-06-02T14:26:36.623","2015-06-02T15:17:10.220","S2-151615","S2-151961","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151831","Concluding on the support of Inter UE transfer for WebRTC based UE","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","Proposes a solution and a conclusion on the support of Inter UE transfer for WebRTC based UE","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13150,"Approved","2015-06-02T14:26:36.653","2015-06-02T15:17:11.127","S2-151523","","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151832","Support of Lawful Interception with the OMR-based e2e media transport solution","Orange","Antoine Mouquet",38438,"pCR","","","Update to the OMR-based e2e media transport solution to comply with the LS reply received from SA WG3-LI (S2-151653).","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13210,"Merged","2015-06-02T14:26:36.670","2015-06-02T15:17:12.047","S2-151748","","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151833","Discussion on LI and E2E media transport","ZTE","Zhendong Li",38521,"pCR","","","This paper discusses the relation between LI and E2E media transport, and concludes that LI does not apply for E2E media.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13230,"Revised","2015-06-02T14:26:36.700","2015-06-02T15:17:12.920","S2-151663","S2-151962","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151834","Solutions for Key issue 5","T-Mobile USA","Christopher Joul",31136,"pCR","","","This document describes three solutions for FS_SEW related to key issue 5","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16050,"Revised","2015-06-02T14:26:36.717","2015-06-02T15:17:13.887","S2-151620","S2-151860","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151835","New Key Issue: Determination of Emergency Call Support","Qualcomm Incorporated","Faccin Stefano",60610,"pCR","","","the contributions adds a new key issues relating to determining whether an emergency call can be supported for the UE in the current location.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16090,"Revised","2015-06-02T14:26:36.730","2015-06-02T15:17:14.793","S2-151695","S2-151861","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151836","Discussion on re-use of existing IMS connectivity","Qualcomm Incorporated","Faccin Stefano",60610,"pCR","","","the contribution discusses the issue related to whether a UE that has a regular PDN connection over WLAN and an IMS registration can re-use the existing connectivity for IMS emergency over WLAN.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16140,"Revised","2015-06-02T14:26:36.763","2015-06-02T15:17:15.680","S2-151694","S2-151862","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151837","Proposed NBIFOM Technical Specification Skeleton","ZTE","Tricci So",44974,"pCR","","","This PCR is to propose the TS skeleton to be adopted and be used as the template to capture the NBIFOM Rel-13 normative text in the TR 23.861 Annex X in the interim until the designated NBIFOM TS is assigned.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11690,"Revised","2015-06-02T14:26:36.777","2015-06-02T15:17:16.570","S2-151559","S2-151955","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151838","Text for TS section 1-4","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Broadcom Corporation, ZTE, Huawei, HiSilicon","Laurent Thiebaut",11066,"pCR","","","This contribution proposes text for section 1-4 of the future TS on NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11730,"Revised","2015-06-02T14:26:36.810","2015-06-02T15:17:17.490","S2-151519","S2-151868","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151839","Text for TS section 5","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Broadcom Corporation, ZTE, Huawei, HiSilicon","Laurent Thiebaut",11066,"pCR","","","This contribution proposes text for section 5 of the future TS on NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11760,"Revised","2015-06-02T14:26:36.827","2015-06-02T15:17:18.380","S2-151520","S2-151869","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151840","Overall procedure to set-up a PDN connection for emergency services","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","description of how the overall process to set up an Emergency session over WLAN would work in phase 1","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16170,"Revised","2015-06-02T14:26:36.840","2015-06-02T15:17:19.270","S2-151521","S2-151863","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151841","Conclusion for FS-SEW phase 1","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","Proposes conclusions for the phase 1 of the FS-SEW study","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16230,"Revised","2015-06-02T14:26:36.857","2015-06-02T15:17:20.173","S2-151609","S2-151864","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151842","Presentation of 23.771 (FS_SEW) to SA","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Presentation of 23.771 (FS_SEW) to SA","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16260,"Revised","2015-06-02T14:26:36.887","2015-06-02T15:17:21.093","S2-151525","S2-152093","Rel-13","","","","","","","","","","","",""]
["S2-151843","Rel-13 Work Item Exception for FS_SEW","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Rel-13 Work Item Exception for FS_SEW","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",0,"Withdrawn","2015-06-02T14:26:36.903","2015-06-02T15:17:21.110","S2-151712","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151844","Rel-13 Work Item Exception for SEW1","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Rel-13 Work Item Exception for SEW1. This is the normative WID spinned-off from the phase 1 of FS_SEW. may have to be moved to AI 7.2.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16310,"Revised","2015-06-02T14:26:36.917","2015-06-02T15:17:22.017","S2-151718","S2-151865","Rel-13","","","","","","","","","","","",""]
["S2-151845","NBIFOM call flows over WLAN","Ericsson, ZTE, Alcatel-Lucent, Alcatel-Lucent Shanghai-Bell, Huawei, HiSilicon","Shabnam Sultana",21207,"pCR","","","Proposes normative call flows over WLAN based on the NBIFOM TR conclusions","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11810,"Revised","2015-06-02T14:26:36.933","2015-06-02T15:17:22.030","S2-151505","S2-151870","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151846","NBIFOM Call Flows - 3GPP initial & additional attach, IP flow mobility & routing rules mapping","ZTE, Alcatel-Lucent, Alcatel-Lucent Shanghai-Bell","Tricci So",44974,"pCR","","","This PCR is to propose normative text to NBIFOM call flows for procedures related to 3GPP access for initial and additional attach, IP flow mobility and routing rules mapping.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11840,"Revised","2015-06-02T14:26:36.967","2015-06-02T15:17:22.920","S2-151565","S2-151953","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151847","NBIFOM Call Flows - Access Removal","ZTE","Tricci So",44974,"pCR","","","This PCR is to propose normative text to NBIFOM call flows for removing an access.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11880,"Revised","2015-06-02T14:26:36.980","2015-06-02T15:17:23.827","S2-151566","S2-151954","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151848","Using RAN Rule in NBIFOM","Huawei, HiSilicon, ZTE","Runze Zhou",60945,"pCR","","","This contribution discusses using RAN Rule in NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11950,"Revised","2015-06-02T14:26:37.013","2015-06-02T15:17:24.713","S2-151531","S2-151956","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151849","Supporting Class of Users","Nokia Networks","Martin Oettl",17230,"CR","","","Summary of change: Adding a NOTE which clarifies that the pool of identities granted towards a third party owning the WWSF may also be a wildcarded range of identities.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13270,"Revised","2015-06-02T14:26:37.027","2015-06-02T15:17:25.713","S2-151702","S2-152113","Rel-13","23.228","13.2.0","eWebRTCi","1134","1","B",null,"","","","",""]
["S2-151850","Avoiding invocation of SRVCC for webRTC flows","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"CR","","","Summary of change: When the operator wants to avoid SRVCC to apply to WebRTC related sessions, the operator should configure PCRF policies so that not to use QCI I for WebRTC traffic","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13320,"Noted","2015-06-02T14:26:37.247","2015-06-02T15:17:26.680","S2-151522","","Rel-13","23.228","13.2.0","eWebRTCi","1131","1","C",null,"","","","",""]
["S2-151851","Configuring AF application identifier value in PCRF to avoid SRVCC","ZTE","Zhendong Li",38521,"CR","","","Summary of change: If the operator wants to avoid SRVCC in WebRTC, the AF and PCRF should be configured with same specific AF application identifier used in PCC procedure to avoid QCI I bearer establishment.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13340,"Revised","2015-06-02T14:26:37.417","2015-06-02T15:17:27.677","S2-151690","S2-152090","Rel-13","23.203","13.3.0","eWebRTCi","0976","1","C",null,"","","","",""]
["S2-151852","Using OMR for WebRTC E2E media transport","ZTE","Zhendong Li",38521,"CR","","","Summary of change: The eP-CSCF should apply OMR to achieve the End to End media transport.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13380,"Withdrawn","2015-06-02T14:26:37.590",null,"S2-151664","","Rel-13","23.228","13.2.0","eWebRTCi","1133","1","B",null,"","","","",""]
["S2-151853","Conclusion for the decomposed architecture","Huawei","Wanling Ye",47063,"pCR","","","It is proposed to conclude the decomposed architecture as an alternative to solution 3 for the final architecture.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13080,"Revised","2015-06-02T14:26:37.747","2015-06-02T15:17:29.520","S2-151726","S2-151960","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151854","Presentation of 23.706 (eWebRTCi) to SA","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Presentation of 23.706 (eWebRTCi) to SA","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13400,"Withdrawn","2015-06-02T14:26:37.777",null,"S2-151524","","Rel-13","","","","","","","","","","","",""]
["S2-151855","Rel-13 Work Item Exception for eWebRTCi","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Rel-13 Work Item Exception for eWebRTCi","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",0,"Revised","2015-06-02T14:26:37.793","2015-06-02T15:17:30.377","S2-151710","S2-152057","Rel-13","","","","","","","","","","","",""]
["S2-151856","NBIFOM Rel-13 Exception Request","ZTE","Tricci So",44974,"other","","","Rel-13 Exception Request for NBIFOM","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",12020,"Revised","2015-06-02T14:26:37.823","2015-06-02T15:17:30.393","S2-151561","S2-152059","Rel-13","","","","","","","","","","","",""]
["S2-151857","NBIFOM TR 23.861 Cover Sheet for TR Conclusions","ZTE","Tricci So",44974,"other","","","NBIFOM Rel-13 study was concluded in SA WG2#108, this tdoc is to prepare the cover sheet to present the concluded NBIFOM TR 23.861 to SA#68 for approval","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",12050,"Revised","2015-06-02T14:26:37.870","2015-06-02T15:17:30.407","S2-151563","S2-152122","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151858","Base Solution for Key issue 3: Handling of UE multiple provided Location Information","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution proposes solution to the key issue # 6 to distinguish multiple UE provided location and access information","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",15960,"Approved","2015-06-02T14:29:37.600","2015-06-02T15:17:30.423","S2-151822","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151859","Utilizing WLAN Information for Emergency Services","Motorola Mobility","Apostolis Salkintzis",22112,"pCR","","","Discusses the information provided by WLANs related to emergency services and proposes how this information may be used by the UE. Solutions are proposed for location determination, emergency call number retrieval and WLAN selection.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16030,"Approved","2015-06-02T14:29:37.617","2015-06-02T15:17:31.267","S2-151824","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151860","Solutions for Key issue 5","T-Mobile USA","Christopher Joul",31136,"pCR","","","This document describes three solutions for FS_SEW related to key issue 5","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16060,"Approved","2015-06-02T14:29:37.630","2015-06-02T15:17:32.123","S2-151834","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151861","New Key Issue: Determination of Emergency Call Support","Qualcomm Incorporated","Faccin Stefano",60610,"pCR","","","the contributions adds a new key issues relating to determining whether an emergency call can be supported for the UE in the current location.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16100,"Revised","2015-06-02T14:29:37.647","2015-06-02T15:17:32.967","S2-151835","S2-151866","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151862","Discussion on re-use of existing IMS connectivity","Qualcomm Incorporated","Faccin Stefano",60610,"pCR","","","the contribution discusses the issue related to whether a UE that has a regular PDN connection over WLAN and an IMS registration can re-use the existing connectivity for IMS emergency over WLAN.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16150,"Approved","2015-06-02T14:29:37.663","2015-06-02T15:17:33.823","S2-151836","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151863","Overall procedure to set-up a PDN connection for emergency services","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","description of how the overall process to set up an Emergency session over WLAN would work in phase 1","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16180,"Revised","2015-06-02T14:29:37.677","2015-06-02T15:17:34.683","S2-151840","S2-151867","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151864","Conclusion for FS-SEW phase 1","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","Proposes conclusions for the phase 1 of the FS-SEW study","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16240,"Approved","2015-06-02T14:29:37.693","2015-06-02T15:17:35.570","S2-151841","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151865","Rel-13 Work Item Exception for SEW1","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Rel-13 Work Item Exception for SEW1. This is the normative WID spinned-off from the phase 1 of FS_SEW. may have to be moved to AI 7.2.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16320,"Revised","2015-06-02T14:29:37.710","2015-06-02T15:17:36.447","S2-151844","S2-152058","Rel-13","","","","","","","","","","","",""]
["S2-151866","New Key Issue: Determination of Emergency Call Support","Qualcomm Incorporated","Faccin Stefano",60610,"pCR","","","the contributions adds a new key issues relating to determining whether an emergency call can be supported for the UE in the current location.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16110,"Approved","2015-06-02T14:35:33.283","2015-06-02T15:17:36.460","S2-151861","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151867","Overall procedure to set-up a PDN connection for emergency services","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","description of how the overall process to set up an Emergency session over WLAN would work in phase 1","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16190,"Approved","2015-06-02T14:35:33.300","2015-06-02T15:17:37.333","S2-151863","","Rel-13","23.771","0.1.0","FS_SEW","","","","","","","","",""]
["S2-151868","Text for TS section 1-4","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Broadcom Corporation, ZTE, Huawei, HiSilicon","Laurent Thiebaut",11066,"pCR","","","This contribution proposes text for section 1-4 of the future TS on NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11740,"Approved","2015-06-02T14:35:33.317","2015-06-02T15:17:38.193","S2-151838","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151869","Text for TS section 5","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Broadcom Corporation, ZTE, Huawei, HiSilicon","Laurent Thiebaut",11066,"pCR","","","This contribution proposes text for section 5 of the future TS on NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11770,"Revised","2015-06-02T14:35:33.330","2015-06-02T15:17:39.037","S2-151839","S2-152085","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151870","NBIFOM call flows over WLAN","Ericsson, ZTE, Alcatel-Lucent, Alcatel-Lucent Shanghai-Bell, Huawei, HiSilicon","Shabnam Sultana",21207,"pCR","","","Proposes normative call flows over WLAN based on the NBIFOM TR conclusions","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11820,"Approved","2015-06-02T14:35:33.347","2015-06-02T15:17:39.893","S2-151845","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151871","Clarification on the overall  architecture related with SCEF","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"CR","","","Summary of change: Clarifies that the SCEF belongs to the HPLMN. Clarifies which southbound interfaces of the SCEF may correspond to raoming. Provides a high level description of the Authorization process for an API","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12490,"Revised","2015-06-02T14:35:33.363","2015-06-02T15:17:40.767","","S2-151943","Rel-13","23.682","13.1.0","AESE","0119","","C",null,"","","","",""]
["S2-151872","Response to S2-151724 Paging optimization analysis","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, NTT Docomo","Nicolas Drevon",16459,"other","","","S2-151724 being exactly the same as R3-150946 provided in RAN WG3, this is a copy of the 'response document' R3-151171. RAN WG3 has the same basis for discussion.","39","6.20.1","TEI13 Category B/C for 3GPP Packet Access",16480,"Available","2015-06-02T14:35:33.427","2015-06-02T15:17:41.640","","","","","","","","","","","","","","",""]
["S2-151873","Draft Agenda for SA WG2#109","SA WG2 Chairman","Frank Mademann",6821,"agenda","","","The meeting agenda.","1","2","Approval of the agenda",10050,"Approved","2015-06-02T14:35:33.440","2015-06-02T15:17:41.657","S2-151432","","","","","","","","","","","","","",""]
["S2-151874","WID for HLCOM normative work","Ericsson","Shabnam Sultana",21207,"WID","","","WID for HLCOM normative work","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16700,"Revised","2015-06-02T14:35:33.457","2015-06-02T15:17:41.670","S2-151494","S2-152131","Rel-13","","","","","","","","","","","",""]
["S2-151875","WID on Support of Emergency services over WLAN - phase 1","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, AT&T, Nokia Networks, Sprint","Laurent Thiebaut",11066,"WID","","","new WID on Support of Emergency services over WLAN - phase 1","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16720,"Revised","2015-06-02T14:35:33.473","2015-06-02T15:17:41.687","S2-151518","S2-152132","Rel-13","","","","","","","","","","","",""]
["S2-151876","Updated WID for Isolated E-UTRAN Operation for Public Safety","General Dynamics UK Limited","Philip Young",27298,"WID","","","Proposal for Rel-13 stage 2 normative work to follow feature study FS_IOPS_St2","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16740,"Revised","2015-06-02T14:35:33.503","2015-06-02T15:17:41.687","S2-151593","S2-152133","Rel-13","","","","","","","","","","","",""]
["S2-151877","Work item on MBMS Enhancements","Nokia Networks","Rainer Liebhart",13470,"WID","","","New Rel-13 WID on MBMS Enhancements.","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16760,"Noted","2015-06-02T14:35:33.517","2015-06-02T15:17:41.717","S2-151658","","Rel-13","","","","","","","","","","","",""]
["S2-151878","New Work Item on Extended DRX cycle for Power Consumption Optimization","Qualcomm Incorporated","Miguel Griot",43100,"WID","","","Proposes a work item to capture normative work derived from the study FS_eDRX","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16780,"Revised","2015-06-02T14:35:33.533","2015-06-02T15:17:41.733","S2-151685","S2-152134","Rel-13","","","","","","","","","","","",""]
["S2-151879","Revised NBIFOM WID for Rel-13","ZTE Corporation","Tricci So",44974,"WID","","","Revised NBIFOM WID to request for dedicated TS assignment to capture the normative procedures and also to update the conclusion date for the normative phase.","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16800,"Revised","2015-06-02T14:35:33.550","2015-06-02T15:17:41.750","S2-151560","S2-152089","Rel-13","","","","","","","","","","","",""]
["S2-151880","SID on VoLTE with S8 Home Routing","NTT DOCOMO","Irfan Ali",50390,"WID","","","Proposes a study item to identify the specification changes needed to enable S8HR as a routing architecture for VoLTE","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10190,"Revised","2015-06-02T14:35:33.567","2015-06-02T15:17:41.767","S2-151740","S2-151973","Rel-4","","","","","","","","","","","",""]
["S2-151881","Group specific NAS Level congestion control for multiple APNs","NTT DOCOMO","SRISAKUL THAKOLSRI",42550,"CR","","","Summary of change: It is proposed that the MME sends a NAS ESM message type that allows the UE belonging to a particular group to be blocked to stop sending a NAS ESM requests for all APNs.","29","6.7","Group based Enhancements (GROUPE)",12910,"Revised","2015-06-02T14:35:33.580","2015-06-02T15:17:41.873","S2-151508","S2-151995","Rel-13","23.401","13.2.0","GROUPE","2866","1","B",null,"","","","",""]
["S2-151882","Group specific NAS level congestion control for multiple APNs","NTT DOCOMO","SRISAKUL THAKOLSRI",42550,"CR","","","Summary of change: It is proposed that the SGSN sends a NAS SM message type that allows the MS belonging to a particular group to be blocked to stop sending a NAS SM requests for all APNs.","29","6.7","Group based Enhancements (GROUPE)",12950,"Revised","2015-06-02T14:35:33.753","2015-06-02T15:17:42.873","S2-151509","S2-151996","Rel-13","23.060","13.2.0","GROUPE","1967","1","B",null,"","","","",""]
["S2-151883","Clarification of Group specific NAS Level congestion control","Huawei","Runze Zhou",60945,"CR","","","Summary of change: Remove 'same APN information is sent to the UE in the rejection message'.","29","6.7","Group based Enhancements (GROUPE)",12990,"Agreed","2015-06-02T14:35:33.907","2015-06-02T15:17:43.840","S2-151668","","Rel-13","23.401","13.2.0","GROUPE","2877","1","F","SP-150237","","","","",""]
["S2-151884","Clarification of Group specific NAS Level congestion control","Huawei","Runze Zhou",60945,"CR","","","Summary of change: Remove 'same APN information is sent to the UE in the rejection message'.","29","6.7","Group based Enhancements (GROUPE)",13010,"Revised","2015-06-02T14:35:34.063","2015-06-02T15:17:44.807","S2-151669","S2-152017","Rel-13","23.060","13.2.0","GROUPE","1971","1","F",null,"","","","",""]
["S2-151885","Group message delivery function and procedure","KPN","Toon Norp",8605,"CR","","","Summary of change: High level description for group messge delivery function and delivery procedures is specified. Rev5: Add option to add option to add randomization of the response time information.","29","6.7","Group based Enhancements (GROUPE)",13040,"Revised","2015-06-02T14:35:34.237","2015-06-02T15:17:45.743","S2-151753","S2-152018","Rel-13","23.682","13.1.0","GROUPE","0094","5","B",null,"","","","",""]
["S2-151886","Proposed Solution B for Key Issue 1 using MBSFN Area Id and/or ECGI list","Motorola Solutions","Val Oprescu",14981,"pCR","","","This contribution proposes a solution for Key issue 1 for Rel-13 which preserves (from Rel-12) the capability of the Application/GCS AS to indicate (rather than rely on RAN-level guesses) which kind of bearer and exactly which area of distribution for the bearer is to be used. The proposal employs MBSFN Area Ids in lieu of service areas and SAIs, to request/modify service. ECGI lists can be used for SC-PTM.","34","6.14","MBMS Enhancements (MBMS_enh)",15180,"Revised","2015-06-02T14:35:34.393","2015-06-02T15:17:46.617","S2-151633","S2-152100","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151887","Dual connectivity handling for the failed E-RAB(s)","Huawei, Hisilicon","Runze Zhou",60945,"CR","","","Summary of change: Add the Dual connectivity handling for the failed E-RAB(s) in the E-RAB Modification procedure","13","5.1","3GPP Packet Access Maintenance",10310,"Agreed","2015-06-02T14:35:34.407","2015-06-02T15:17:47.600","S2-151666","","Rel-12","23.401","12.8.0","TEI12, LTE_SC_enh_dualC","2875","1","F","SP-150230","","","","",""]
["S2-151888","Dual connectivity handling for the failed E-RAB(s)","Huawei, Hisilicon","Runze Zhou",60945,"CR","","","Rel-13 mirror CR: Summary of change: Add the Dual connectivity handling for the failed E-RAB(s) in the E-RAB Modification procedure","13","5.1","3GPP Packet Access Maintenance",10330,"Agreed","2015-06-02T14:35:34.580","2015-06-02T15:17:49.300","S2-151667","","Rel-13","23.401","13.2.0","TEI12, LTE_SC_enh_dualC","2876","1","A","SP-150230","","","","",""]
["S2-151889","Clarification on Network Triggered Service Request","LG Electronics","Jinsook Ryu",39022,"CR","","","Summary of change: - Ambiguous pronoun 'In that case' is clarified as exact case that 'When a Downlink Data Notification Reject message is received'  - Reject control signalling case also added for ISR is not activated case","13","5.1","3GPP Packet Access Maintenance",10370,"Agreed","2015-06-02T14:35:34.750","2015-06-02T15:17:51.047","S2-151551","","Rel-12","23.401","12.8.0","SAES, TEI12","2868","1","F","SP-150283","","","","",""]
["S2-151890","Clarification on Network Triggered Service Request","LG Electronics","Jinsook Ryu",39022,"CR","","","Rel-13 mirror CR: Summary of change: - Ambiguous pronoun 'In that case' is clarified as exact case that 'When a Downlink Data Notification Reject message is received'  - Reject control signalling case also added for ISR is not activated case","13","5.1","3GPP Packet Access Maintenance",10390,"Agreed","2015-06-02T14:35:34.907","2015-06-02T15:17:52.777","S2-151552","","Rel-13","23.401","13.2.0","SAES, TEI12","2869","1","A","SP-150283","","","","",""]
["S2-151891","[DRAFT] Reply LS on service authorisation procedure based on the location","SA WG2","Jinguo Zhu",32987,"LS out","","","To: CT WG1","13","5.1","3GPP Packet Access Maintenance",10450,"Revised","2015-06-02T14:35:35.093","2015-06-02T15:17:54.417","","S2-151990","Rel-12","","","","","","","","S2-151442","CT WG1","-"]
["S2-151892","Clarification on service authorisation procedure based on location","ZTE, ZTE Mobile","Jinguo Zhu",32987,"CR","","","Summary of change: It is clarfied that the authorisation info provided to the UE applies to the serving PLMN which is obtained from the HSS.","13","5.1","3GPP Packet Access Maintenance",10490,"Revised","2015-06-02T14:35:35.110","2015-06-02T15:17:54.527","S2-151721","S2-151989","Rel-12","23.303","12.4.0","ProSe","0173","1","F",null,"","","","",""]
["S2-151893","AESE, MONTE drafting report","Intel (Rapportuer)","Puneet Jain",36283,"report","","","AESE, MONTE drafting report","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12520,"Available","2015-06-02T14:35:35.267","2015-06-02T15:17:55.400","","","","","","","","","","","","","","",""]
["S2-151894","[DRAFT] Reply LS on network feature support for ProSe Discovery","SA WG2","Haris Zisimopoulos",41602,"LS out","","","Provides answer to CT WG1 LS on network feature support for ProSe","13","5.1","3GPP Packet Access Maintenance",10540,"Revised","2015-06-02T14:35:35.280","2015-06-02T15:17:55.430","S2-151581","S2-152064","Rel-12","","","","","","","","S2-151443","CT WG1","SA WG1, RAN WG2"]
["S2-151895","Correction of UE identities used between ProSe Function for service authorization","Qualcomm Incorporated","Haris Zisimopoulos",41602,"CR","","","Summary of change: Update the procedure in 5.2.2.4 to allow either IMSI or MSISDN to be used as the UE identifier.","13","5.1","3GPP Packet Access Maintenance",10600,"Revised","2015-06-02T14:35:35.297","2015-06-02T15:17:55.557","S2-151579","S2-152065","Rel-12","23.303","12.4.0","ProSe","0170","1","F",null,"","","","",""]
["S2-151896","UE context clarification","Telecom Italia, ZTE","Mario Madella",23765,"CR","","","Summary of change: - Replaced the misleading text in step 2 of the Announce and Monitor request procedures with new text at the very end of each procedure. - Added a clarification on the behavior of the ProSe Function when the last entry is removed from the UE context.","13","5.1","3GPP Packet Access Maintenance",10670,"Agreed","2015-06-02T14:35:35.467","2015-06-02T15:17:56.553","S2-151557","","Rel-12","23.303","12.4.0","ProSe-SA2","0165","1","F","SP-150226","","","","",""]
["S2-151897","Clarification of dual classifier solution","China Mobile, CATR","Tao Sun",54129,"pCR","","","Provide clarification of the dual classifier solution","33","6.13","Flexible Mobile Service Steering (FMSS)",14720,"Revised","2015-06-02T14:35:35.623","2015-06-02T15:17:57.427","S2-151641","S2-151937","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151898","Aspects of metadata transfer and application reporting support for TDF/PCEF","Allot Communications, Cisco, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Comverse, SPRINT, Openet Telecom, Sandvine Incorporated","Alla Goldner",42718,"pCR","","","This contribution addresses aspects of metadata transfer and of application reporting for traffic steering policy generation for the Sd/Gx based solutions.","33","6.13","Flexible Mobile Service Steering (FMSS)",14760,"Revised","2015-06-02T14:35:35.640","2015-06-02T15:17:58.287","S2-151486","S2-152042","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151899","Aspects of application identification for FMSS solution","Allot Communications, Cisco, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Huawei, HiSilicon, Comverse, Openet Telecom, Sandvine Incorporated","Alla Goldner",42718,"pCR","","","This contribution analyses requirements related to application identification and adds points to reflect application identification handling.","33","6.13","Flexible Mobile Service Steering (FMSS)",14790,"Approved","2015-06-02T14:35:35.670","2015-06-02T15:17:59.160","S2-151487","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151900","Updates to St based architecture solution","Ericsson, AT&T","Shabnam Sultana",21207,"pCR","","","Proposes updates to the solution based on St interface in order to resolve open issues and to clarify the relation with IETF/ONF architectures.","33","6.13","Flexible Mobile Service Steering (FMSS)",14810,"Revised","2015-06-02T14:35:35.687","2015-06-02T15:18:00.063","S2-151504","S2-152043","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151901","LS from GSMA RAG: LS on VoLTE Roaming Charging","GSMA RAG","Maurice Pope",648,"LS in","","","GSMA Networks Group (NG) is currently assessing the scenario where operators would implement VoLTE Roaming according to the S8HR (Home Routing) architecture. In that context, questions on charging aspects have come up, and GSMA would like to address to 3GPP for further consideration.","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10270,"Noted","2015-06-02T14:35:35.703","2015-06-02T15:18:00.923","","","","","","","","","","",null,null,null,"RAG 15 Doc 007"]
["S2-151902","LS from RAN WG2: Response LS on Paging Optimization considering supported frequency bands","RAN WG2","Maurice Pope",648,"LS in","","","RAN WG2 would like to thank RAN WG3 for the LS on Paging Optimization considering supported frequency bands. RAN WG2 discussed how to convey UE supported frequency bands in RRC container and agreed: - RAN WG2 supports the proposed paging enhancement in RAN WG3 LS and will aim for a solution not impacting the UE, i.e., the eNB will derive the supported bands from the existing UE capabilities and provide them to the MME. The signalling details (e.g. reuse original container or introduce a new container) require further discussion. Also other enhancements affecting paging may be taken into account (e.g. Rel-13 MTC LC/CE). Action: RAN WG2 respectfully asks RAN WG3, SA WG2 to take the above into account for their further work.","6","4.1","Common issues and Incoming LSs",10130,"Postponed","2015-06-02T14:35:35.717","2015-06-02T15:18:00.923","","S2-152147","Rel-13","","","","","","","",null,null,null,"R2-152789"]
["S2-151903","Support for Monitoring Events","Intel, Cisco","Maulik Vaidya",44517,"CR","","","Summary of change: High level description for Monitoring Events feature. Support for Gn/Gp SGSN is clarified.","28","6.6","Monitoring Enhancements (MONTE)",12700,"Revised","2015-06-02T14:35:35.733","2015-06-02T15:18:01.047","S2-151483","S2-152035","Rel-13","23.060","13.2.0","MONTE","1961","4","B",null,"","","","",""]
["S2-151904","Introduction of monitoring procedures","Huawei, HiSilicon, Intel, Alcatel-Lucent, Cisco, LG Electronics","Frank Mademann",6821,"CR","","","Summary of change: The procedures for supporting monitoring configuration via MME/SGSN and via HSS are introduced. The procedure for reporting of Monitoring Events from the HSS or the MME/SGSN is also introduced.","28","6.6","Monitoring Enhancements (MONTE)",12730,"Revised","2015-06-02T14:35:35.890","2015-06-02T15:18:02.013","S2-151736","S2-152077","Rel-13","23.682","13.1.0","MONTE","0097","4","B",null,"","","","",""]
["S2-151905","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent","Shabnam Sultana",21207,"CR","","","Summary of change: Introduced description of the functions for High latency communication.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14450,"Revised","2015-06-02T14:35:36.060","2015-06-02T15:18:02.997","S2-151496","S2-152019","Rel-13","23.682","13.1.0","TEI13","0106","1","B",null,"","","","",""]
["S2-151906","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent","Shabnam Sultana",21207,"CR","","","Summary of change: Changes according to conclusions in the FS_HLCOM study TR 23.709.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14490,"Revised","2015-06-02T14:35:36.233","2015-06-02T15:18:03.980","S2-151497","S2-152020","Rel-13","23.401","13.2.0","TEI13","2862","1","B",null,"","","","",""]
["S2-151907","Clarification on solution for background traffic","Ericsson","Shabnam Sultana",21207,"pCR","","","Clarifications to the general approach to align with current PCC specifications.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12110,"Approved","2015-06-02T14:35:36.403","2015-06-02T15:18:04.823","S2-151604","","Rel-13","23.708","1.1.0","AESE","","","","","","","","",""]
["S2-151908","Detailed description for informing about potential network issues","Huawei, HiSilicon, China Mobile, Cisco","Mirko Schramm",23396,"CR","","","Summary of change: It is proposed to document the detailed functional description for informing 3rd party about potential network issues.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12160,"Revised","2015-06-02T14:35:36.420","2015-06-02T15:18:05.807","S2-151672","S2-152041","Rel-13","23.682","13.1.0","AESE","0116","1","B",null,"","","","",""]
["S2-151909","Architectural updates for AESE feature","China Mobile","Aihua Li",58162,"CR","","","Summary of change: Updates to architecture for AESE feature by adding new reference point Ns(RCAF- SCEF).","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12140,"Agreed","2015-06-02T14:35:36.593","2015-06-02T15:18:06.773","S2-151549","","Rel-13","23.682","13.1.0","AESE","0109","1","B","SP-150235","","","","",""]
["S2-151910","Introducing SCEF and RCAF Reference Point","China Mobile","Aihua Li",58162,"CR","","","Summary of change: Add description of new reference points Ns(RCAF- SCEF) that is to be introduced in TS 23.682 as part of AESE feature.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12190,"Revised","2015-06-02T14:35:36.763","2015-06-02T15:18:07.770","S2-151553","S2-152028","Rel-13","23.002","13.1.0","AESE","0284","1","B",null,"","","","",""]
["S2-151911","Implementing AESE Solution on providing predictable communication patterns of a UE to the MME","NEC, CATT, Samsung","Andreas Kunz",35384,"CR","","","Summary of change: Add functional description and information flow for providing communication pattern parameters to the MME via HSS.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12230,"Revised","2015-06-02T14:35:36.920","2015-06-02T15:18:08.737","S2-151595","S2-152029","Rel-13","23.682","13.1.0","AESE","0113","1","B",null,"","","","",""]
["S2-151912","HSS and MME updates for AESE 3GPP resource optimizations based on providing predictable communication patterns of a UE to the MME","NEC, CATT","Andreas Kunz",35384,"CR","","","Summary of change: Updates to the HSS and MME for the AESE solution on 3GPP resource optimizations based on providing predictable communication patterns of a UEto the MME.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12270,"Revised","2015-06-02T14:35:37.107","2015-06-02T15:18:09.720","S2-151596","S2-152030","Rel-13","23.401","13.2.0","AESE","2872","1","B",null,"","","","",""]
["S2-151913","Setting up an AS session with required QoS","Intel, Huawei, Alcatel-Lucent","Puneet Jain",36283,"CR","","","This provides description of setting up an AS session with required QoS.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12310,"Agreed","2015-06-02T14:35:37.293","2015-06-02T15:18:10.733","S2-151769","","Rel-13","23.682","13.1.0","AESE","0117","1","B","SP-150235","","","","",""]
["S2-151914","[DRAFT] LS on the risk of IMSI exposure at the SCEF","SA WG2","Laurent Thiebaut",11066,"LS out","","","SA WG2 thanks SA WG3 for your LS on the risk of IMSI exposure at the SCEF. SA WG2 notes that TS 23.682 v13.0 clause 4.2 says:The trust domain (see figure 4.2-2) cover entities that are protected by adequate network domain security. The entities and interfaces within the trust domain may all be within one operator's control, or some may be controlled by a trusted business partner which has a trust relationship with the operator e.g. another operator or a 3rd party. When not under the control of the PLMN operator, it is up to the PLMN operator to ensure that access to the PLMN operator's network from the SCEF is deployed in a manner consistent with security principles of the 3GPP network as outlined by SA WG3 security specifications.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12080,"Revised","2015-06-02T14:35:37.467","2015-06-02T15:18:11.623","S2-151481","S2-152070","Rel-13","","","","","","","","S2-151464","SA WG3"]
["S2-151915","Proposed new Key Issue: 'MBMS Congestion' Mitigation for Rel-13","Motorola Solutions","Val Oprescu",14981,"pCR","","","Proposes the addition of the Key Issue to study for MBMS congestion management in Rel-13","34","6.14","MBMS Enhancements (MBMS_enh)",15220,"Revised","2015-06-02T14:35:37.480","2015-06-02T15:18:11.640","S2-151640","S2-152101","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151916","Route MBMS Session Start using SAI derived from TAI. Describe broadcast area with ECGIs.","Vodafone","Chris Pudney",1122,"pCR","","","Describes an additional/complementary solution for simple O&M of group areas for e.g. Public Safety users.","34","6.14","MBMS Enhancements (MBMS_enh)",15260,"Approved","2015-06-02T14:35:37.513","2015-06-02T15:18:12.543","S2-151739","","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151917","MBMS_Enh Solution Evaluation and Conclusion","Alcatel-Lucent","Mike Dolan",1692,"pCR","","","This contribution provides an evaluation of Solutions 1 and 2 and a conclusion for TR 23.741 (MBMS_Enh).","34","6.14","MBMS Enhancements (MBMS_enh)",15280,"Noted","2015-06-02T14:35:37.527","2015-06-02T15:18:13.450","S2-151477","","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-151918","Change of name for parameter FlowID","Motorola Solutions","Val Oprescu",14981,"CR","","","Summary of change: Replace the parameter name 'FlowID' with 'Tag' in messages on the MB2 interface. Some editorials corrected (Figure numbering).","13","5.1","3GPP Packet Access Maintenance",10770,"Noted","2015-06-02T14:35:37.560","2015-06-02T15:18:14.433","S2-151636","","Rel-12","23.468","12.4.0","GCSE_LTE","0061","1","F",null,"","","","",""]
["S2-151919","Work Planning work sheet","Samsung","Erik Guttman",18782,"other","","","Status of SA WG2 Work Items","43","7.2","Review of the Work Plan",16820,"Revised","2015-06-02T14:35:37.730","2015-06-02T15:18:15.320","","S2-152060","","","","","","","","","","","","",""]
["S2-151920","Clean up and evaluation/conclusion on issues with one solution","Qualcomm Incorporated","Miguel Griot",43100,"pCR","","","Resolves editor's notes, general clean up and adds evaluation for issues that have only one solution captured in TR. Concludes that these solutions are feasible and target for normative work.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15340,"Approved","2015-06-02T14:35:37.747","2015-06-02T15:18:15.337","S2-151681","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151921","Update to eDRX in Idle Mode solution","NEC","Iskren Ianev",59515,"pCR","","","Abstract of the contribution: This contribution points out at the need for synchronisation between the UE and the network in case of the extended DRX cycle length longer than the System Frame. Such a statement has already been captured in TR23.887. This contribution proposes to transfer this statement from TR23.887 to the eDRX study TR23.770. Additionally, it proposes a Note for the eDRX parameters over NAS dependence on the agreed solution for UE/network paging coordination.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15360,"Approved","2015-06-02T14:35:37.777","2015-06-02T15:18:16.240","S2-151583","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151922","Extended DRX in Idle","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution provides details to the solution 5.2.1 Paging coordination between CN and UE","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15380,"Revised","2015-06-02T14:35:37.793","2015-06-02T15:18:17.177","S2-151602","S2-152102","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151923","Evaluation of paging strategy solutions for Idle mode Issue 2","Qualcomm Incorporated","Miguel Griot",43100,"pCR","","","Evaluates paging strategy solutions for idle mode Issue 2, and concludes that it is more efficient that a RAN based solution for determining the paging occasion is more efficient and should be adopted assuming RAN adopts a RAN based approach.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15420,"Approved","2015-06-02T14:35:37.823","2015-06-02T15:18:18.067","S2-151682","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151924","GTP-C re-transmissions","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution updates a solution for GTP-C re-transmissions and provides an evaluation of the two available solutions","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15460,"Revised","2015-06-02T14:35:37.840","2015-06-02T15:18:19.017","S2-151606","S2-152025","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151925","solution evaluation on GTP-C retransmission","Huawei","Runze Zhou",60945,"pCR","","","solution evaluation on GTP-C retransmission","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15490,"Approved","2015-06-02T14:35:37.870","2015-06-02T15:18:19.937","S2-151670","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151926","MT SMS for Extended DRX","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution provides a solution for handling MT SMS for extended C-DRX","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15510,"Revised","2015-06-02T14:35:37.903","2015-06-02T15:18:20.827","S2-151601","S2-152026","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151927","Clarifications on the activation of IOPS in eNBs","Nokia Networks","György Wolfner",31366,"pCR","","","This paper proposes clarifications on the activation of IOPS in eNBs and some other minor clarifications.","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15740,"Approved","2015-06-02T14:35:37.917","2015-06-02T15:18:21.700","S2-151587","","Rel-13","23.797","0.1.0","FS_IOPS_St2","","","","","","","","",""]
["S2-151928","Decouple SA2 study report from SA3 study of IOPS security solution","General Dynamics UK Ltd.","Philip Young",27298,"pCR","","","This contribution proposes text to decouple the SA WG2 study report from the SA WG3 study of an IOPS security solution","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15770,"Approved","2015-06-02T14:35:37.950","2015-06-02T15:18:22.577","S2-151590","","Rel-13","23.797","0.1.0","FS_IOPS_St2","","","","","","","","",""]
["S2-151929","Conclusion for IOPS study","Samsung, General Dynamics UK Ltd., Nokia Networks","Curt Wong",42596,"pCR","","","This paper is trying to conclude TR 23.797 and to allow normative phase to be started at next meeting (assuming exception is granted by TSG SA).","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15800,"Approved","2015-06-02T14:35:37.980","2015-06-02T15:18:23.480","S2-151617","","Rel-13","23.797","0.1.0","FS_IOPS_St2","","","","","","","","",""]
["S2-151930","Cover Sheet for TR 23.797 for Information and Approval at TSG SA","FS_IOPS_St2 Rapporteur (General Dynamics UK Ltd.)","Philip Young",27298,"TS or TR","","","This contribution proposes a cover page for submitting TR 23.797 to SA plenary for Information and Approval","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",0,"Revised","2015-06-02T14:35:37.997","2015-06-02T15:18:24.463","S2-151592","S2-152039","Rel-13","23.797","0.1.0","FS_IOPS_St2","","","","","","","","",""]
["S2-151931","[DRAFT] LS on progress of IOPS in SA WG2 and security study dependencies","SA WG2","Philip Young",27298,"LS out","","","To: SA WG3","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15840,"Revised","2015-06-02T14:35:38.043","2015-06-02T15:18:25.400","","S2-152040","Rel-13","","","","","","","",null,"SA WG3","-"]
["S2-151932","On the e-CDRX period","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, LG Electronics, Huawei, Qualcomm Inc.","Alessio Casati",13542,"pCR","","","This paper addresses the need to identify the expected range of the e-CDRX before we move to normative phase, in order to have a stable selection criterion for solutions.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15550,"Revised","2015-06-02T14:35:38.073","2015-06-02T15:18:25.430","S2-151657","S2-152027","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151933","Conclusion of FMSS","China Mobile, Broadcom, CATR, China Telecom, China Unicom","Tao Sun",54129,"pCR","","","This paper propose a conclusion for FMSS in R-13","33","6.13","Flexible Mobile Service Steering (FMSS)",15000,"Revised","2015-06-02T14:35:38.090","2015-06-02T15:18:26.303","S2-151530","S2-151934","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151934","Conclusion of FMSS","China Mobile, Broadcom, CATR, China Telecom, China Unicom","Tao Sun",54129,"pCR","","","This paper propose a conclusion for FMSS in R-13","33","6.13","Flexible Mobile Service Steering (FMSS)",15010,"Revised","2015-06-02T14:38:52","2015-06-02T15:18:27.177","S2-151933","S2-151993, S2-152047","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151935","Address metadata report related Editor's notes for St based solution","China Telecom","Jinyan Li",46923,"pCR","","","This contribution intends to resolve the metadata reporting related editor's note for the St based solutions.","33","6.13","Flexible Mobile Service Steering (FMSS)",14840,"Revised","2015-06-02T14:38:52.017","2015-06-02T15:18:28.037","S2-151507","S2-152044","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151936","Details on how to handle report of changes of metadata over St","Ericsson","Shabnam Sultana",21207,"pCR","","","This paper proposes to remove Editors note on metadaa reporting over St interface.","33","6.13","Flexible Mobile Service Steering (FMSS)",14870,"Revised","2015-06-02T14:38:52.047","2015-06-02T15:18:28.940","S2-151603","S2-152045","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151937","Clarification of dual classifier solution","China Mobile, CATR","Tao Sun",54129,"pCR","","","Provide clarification of the dual classifier solution","33","6.13","Flexible Mobile Service Steering (FMSS)",14730,"Approved","2015-06-02T14:38:52.063","2015-06-02T15:18:29.797","S2-151897","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151938","Resolving FMSS editor's note for solutions 1.1 and 1.2 of key issue #1","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Allot Communications, Cisco","Nicolas Drevon",16459,"pCR","","","This paper intends to solve the editor's note related to the way the SFC Controller receives traffic steering policies when leveraging the ONF work.","33","6.13","Flexible Mobile Service Steering (FMSS)",14900,"Approved","2015-06-02T14:38:52.077","2015-06-02T15:18:30.750","S2-151699","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151939","Possible Solutions for Metadata Transferring","Huawei, HiSilicon","Shufeng Shi",56675,"pCR","","","This contribution proposes serveral possible solutions for metadata transferring.","33","6.13","Flexible Mobile Service Steering (FMSS)",14920,"Revised","2015-06-02T14:38:52.093","2015-06-02T15:18:31.670","S2-151701","S2-152046","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151940","Addition of resource management for background data transfer feature","NTT DOCOMO, Huawei, Hisilicon,","Syed Husain",14749,"CR","","","Summary of change: This provides description of resource management for background data transfer.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12330,"Revised","2015-06-02T14:38:52.110","2015-06-02T15:18:32.763","S2-151599","S2-152072","Rel-13","23.682","13.1.0","AESE","0114","1","B",null,"","","","",""]
["S2-151941","Resource management for background data transfer via Rx","Huawei, HiSilicon, NTT DOCOMO","Mirko Schramm",23396,"CR","","","Summary of change: It is proposed to document the detailed functional description of resource management for background data transfer via Rx.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12360,"Revised","2015-06-02T14:38:52.297","2015-06-02T15:18:33.870","S2-151678","S2-152073","Rel-13","23.203","13.3.0","AESE","0975","1","B",null,"","","","",""]
["S2-151942","Change the chargeable party at the session set-up or during the session","Intel","Puneet Jain",36283,"CR","","","This provides description of change the chargeable party at the session set-up or during the session","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12460,"Revised","2015-06-02T14:38:52.453","2015-06-02T15:18:34.917","S2-151770","S2-152033","Rel-13","23.682","13.1.0","AESE","0118","1","B",null,"","","","",""]
["S2-151943","Clarification on the overall  architecture related with SCEF","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"CR","","","Summary of change: Clarifies that the SCEF belongs to the HPLMN. Clarifies which southbound interfaces of the SCEF may correspond to raoming. Provides a high level description of the Authorization process for an API","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12500,"Revised","2015-06-02T14:38:52.623","2015-06-02T15:18:36.023","S2-151871","S2-152075","Rel-13","23.682","13.1.0","AESE","0119","1","C",null,"","","","",""]
["S2-151944","Cover Sheet for TR 23.708 for Approval at TSG SA","Intel","Puneet Jain",36283,"TS or TR","","","Proposes a cover page for submitting TR 23.708 v1.2.0 to SA#68 plenary for Approval","27","6.5","Architecture Enhancements for Service Exposure (AESE)",0,"Revised","2015-06-02T14:38:52.810","2015-06-02T15:18:36.910","S2-151513","S2-152031","Rel-13","23.708","1.1.0","AESE","","","","","","","","",""]
["S2-151945","[DRAFT] LS on 3GPP Rel-13 MTC features for service capability exposure","SA WG2","Puneet Jain",36283,"LS out","","","LS to GSMA, OMA, oneM2M on Rel-13 MTC feature","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12420,"Revised","2015-06-02T14:38:52.857","2015-06-02T15:18:37.833","S2-151514","S2-152032","Rel-13","","","","","","","",null,"GSMA, OMA, oneM2M","TSG CT, TSG SA"]
["S2-151946","Enhancing roaming architecture for Service Exposure","Ericsson, AT&T, Nokia Networks","Shabnam Sultana",21207,"CR","","","Summary of change: Introduce a lightweight proxy to aggregate communication with external parties.","28","6.6","Monitoring Enhancements (MONTE)",12640,"Revised","2015-06-02T14:38:52.890","2015-06-02T15:18:37.957","S2-151503","S2-152034","Rel-13","23.682","13.1.0","AESE, MONTE","0107","1","B",null,"","","","",""]
["S2-151947","Reserved for Puneet's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",12530,"Withdrawn","2015-06-02T14:38:53.060",null,"","","","","","","","","","","","","","",""]
["S2-151948","Reserved for Puneet's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",12540,"Withdrawn","2015-06-02T14:38:53.077",null,"","","","","","","","","","","","","","",""]
["S2-151949","Reserved for Puneet's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",12550,"Withdrawn","2015-06-02T14:38:53.093",null,"","","","","","","","","","","","","","",""]
["S2-151950","Reserved for Puneet's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",12560,"Withdrawn","2015-06-02T14:38:53.093",null,"","","","","","","","","","","","","","",""]
["S2-151951","Reserved for Puneet's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",12570,"Withdrawn","2015-06-02T14:38:53.107",null,"","","","","","","","","","","","","","",""]
["S2-151952","Reserved for Puneet's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",12580,"Withdrawn","2015-06-02T14:38:53.123",null,"","","","","","","","","","","","","","",""]
["S2-151953","NBIFOM Call Flows - 3GPP initial & additional attach, IP flow mobility & routing rules mapping","ZTE, Alcatel-Lucent, Alcatel-Lucent Shanghai-Bell","Tricci So",44974,"pCR","","","This PCR is to propose normative text to NBIFOM call flows for procedures related to 3GPP access for initial and additional attach, IP flow mobility and routing rules mapping.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11850,"Revised","2015-06-02T14:38:53.140","2015-06-02T15:18:39.563","S2-151846","S2-152086","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151954","NBIFOM Call Flows - Access Removal","ZTE","Tricci So",44974,"pCR","","","This PCR is to propose normative text to NBIFOM call flows for removing an access.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11890,"Revised","2015-06-02T14:38:53.153","2015-06-02T15:18:40.453","S2-151847","S2-152087","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151955","Proposed NBIFOM Technical Specification Skeleton","ZTE","Tricci So",44974,"pCR","","","This PCR is to propose the TS skeleton to be adopted and be used as the template to capture the NBIFOM Rel-13 normative text in the TR 23.861 Annex X in the interim until the designated NBIFOM TS is assigned.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11700,"Revised","2015-06-02T14:38:53.187","2015-06-02T15:18:41.343","S2-151837","S2-152084","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151956","Using RAN Rule in NBIFOM","Huawei, HiSilicon, ZTE","Runze Zhou",60945,"pCR","","","This contribution discusses using RAN Rule in NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11960,"Revised","2015-06-02T14:38:53.200","2015-06-02T15:18:42.200","S2-151848","S2-152088","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-151957","[DRAFT] Reply to LS from SA WG4: Reply LS on TR 26.924 Study on improved end-to-end QoS handling","SA WG2","Belen Pancorbo",4022,"LS out","","","To: SA WG4. CC: CT WG1, CT WG3, CT WG4","21","6.1.2","Rel-13 PCC/QoS Maintenance",11100,"Revised","2015-06-02T14:38:53.233","2015-06-02T15:18:43.153","S2-151829","S2-151958","Rel-13","","","","","","","","S2-151654","SA WG4","CT WG1, CT WG3, CT WG4"]
["S2-151958","[DRAFT] Reply to LS from SA WG4: Reply LS on TR 26.924 Study on improved end-to-end QoS handling","SA WG2","Belen Pancorbo",4022,"LS out","","","To: SA WG4. CC: CT WG1, CT WG3, CT WG4","21","6.1.2","Rel-13 PCC/QoS Maintenance",11110,"Revised","2015-06-02T14:42:15.787","2015-06-02T15:18:43.167","S2-151957","S2-152081","Rel-13","","","","","","","","S2-151654","SA WG4","CT WG1, CT WG3, CT WG4"]
["S2-151959","Alignment of RUCI reporting restrictions' basis for UPCON","China Telecom, ZTE","Jinyan Li",46923,"CR","","","Summary of change: Align the reporting restrictions on per UE per APN basis.","21","6.1.2","Rel-13 PCC/QoS Maintenance",11160,"Agreed","2015-06-02T14:42:15.800","2015-06-02T15:18:43.277","S2-151825","","Rel-13","23.203","13.3.0","UPCON","0978","2","F","SP-150231","","","","",""]
["S2-151960","Conclusion for the decomposed architecture","Huawei","Wanling Ye",47063,"pCR","","","It is proposed to conclude the decomposed architecture as an alternative to solution 3 for the final architecture.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13090,"Approved","2015-06-02T14:42:15.973","2015-06-02T15:18:44.167","S2-151853","","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151961","Concluding on the Solution 7.2.1: WebRTC related IMS service control","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"pCR","","","Updates the solution 7.2.1and proposes a conclusion on the support of WebRTC related IMS service control","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13130,"Approved","2015-06-02T14:42:16.003","2015-06-02T15:18:45.197","S2-151830","","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151962","Discussion on LI and E2E media transport","ZTE","Zhendong Li",38521,"pCR","","","This paper discusses the relation between LI and E2E media transport, and concludes that LI does not apply for E2E media.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13240,"Approved","2015-06-02T14:42:16.020","2015-06-02T15:18:46.053","S2-151833","","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-151963","Reserved for Krisztian's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16340,"Withdrawn","2015-06-02T14:42:16.037",null,"","","","","","","","","","","","","","",""]
["S2-151964","Reserved for Krisztian's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16350,"Withdrawn","2015-06-02T14:42:16.050",null,"","","","","","","","","","","","","","",""]
["S2-151965","Reserved for Krisztian's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16360,"Withdrawn","2015-06-02T14:42:16.067",null,"","","","","","","","","","","","","","",""]
["S2-151966","Reserved for Krisztian's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16370,"Withdrawn","2015-06-02T14:42:16.067",null,"","","","","","","","","","","","","","",""]
["S2-151967","Reserved for Krisztian's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16380,"Withdrawn","2015-06-02T14:42:16.083",null,"","","","","","","","","","","","","","",""]
["S2-151968","Reserved for Krisztian's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16390,"Withdrawn","2015-06-02T14:42:16.097",null,"","","","","","","","","","","","","","",""]
["S2-151969","Reserved for Krisztian's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16400,"Withdrawn","2015-06-02T14:42:16.113",null,"","","","","","","","","","","","","","",""]
["S2-151970","Reserved for Krisztian's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16410,"Withdrawn","2015-06-02T14:42:16.127",null,"","","","","","","","","","","","","","",""]
["S2-151971","Reserved for Krisztian's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16420,"Withdrawn","2015-06-02T14:42:16.143",null,"","","","","","","","","","","","","","",""]
["S2-151972","Reserved for Krisztian's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16430,"Withdrawn","2015-06-02T14:42:16.143",null,"","","","","","","","","","","","","","",""]
["S2-151973","SID on VoLTE with S8 Home Routing","NTT DOCOMO","Irfan Ali",50390,"WID","","","Proposes a study item to identify the specification changes needed to enable S8HR as a routing architecture for VoLTE","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10200,"Revised","2015-06-02T14:42:16.160","2015-06-02T15:18:47.007","S2-151880","S2-152049","Rel-4","","","","","","","","","","","",""]
["S2-151974","DRAFT [LS OUT] Rely LS on VoLTE Roaming Architecture","SA WG2","Motohiro Abe",57779,"LS out","","","Replies to two GSMA LS (S2-151434 and S2-151440) on VoLTE Roaming Architecture. SA WG2 has approved SID on VoLTE with S8HR.","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10240,"Revised","2015-06-02T14:42:16.177","2015-06-02T15:18:47.020","S2-151741","S2-152062","Rel-4","","","","","","","","S2-151434","TSG SA, TSG CT, GSMA PMSC, GSMA RAG","CT WG3, SA WG3-LI, SA WG5, SA WG3"]
["S2-151975","Introduction of Charging Principles for Monitoring Events feature","Cisco","Maulik Vaidya",44517,"CR","","","Summary of change: Based on agreeements in S2-151455, high-level charging principles to be used for Monitoring Events feature are added.","28","6.6","Monitoring Enhancements (MONTE)",12780,"Revised","2015-06-02T14:42:16.207","2015-06-02T15:18:47.147","S2-151458","S2-152036","Rel-13","23.682","13.1.0","MONTE","0104","1","B",null,"","","","",""]
["S2-151976","Monitoring event configuration in the HSS and MME","Samsung","Sung Hwan Won",46717,"CR","","","Summary of change: Monitoring Event Configuration Container is added in the HSS data/MME MM contexts.","28","6.6","Monitoring Enhancements (MONTE)",12810,"Revised","2015-06-02T14:42:16.363","2015-06-02T15:18:48.160","S2-151585","S2-152037","Rel-13","23.401","13.2.0","MONTE","2871","1","B",null,"","","","",""]
["S2-151977","Monitoring event configuration in the HSS and SGSN","Samsung","Sung Hwan Won",46717,"CR","","","Summary of change: Monitoring Event Configuration Container is added in the HSS data/SGSN MM contexts.","28","6.6","Monitoring Enhancements (MONTE)",12840,"Revised","2015-06-02T14:42:16.533","2015-06-02T15:18:49.157","S2-151586","S2-152038","Rel-13","23.060","13.2.0","MONTE","1968","1","B",null,"","","","",""]
["S2-151978","Monitoring via PCRF","Ericsson","Shabnam Sultana",21207,"CR","","","Summary of change: Reporting current user location and communication failure via PCRF as defined in 23.203. Clarifications are included in this version as follows: - A note is added to sub-clause 5.n.x.2 to clarify that the UE IP address is supposed not to be NAT'ed, the reason is that PCC framework is reused as currently defined that places the responsibility to provide the UE IP address known at the PCEF over Rx interface, the SCEF has no capabilities to translate the UE IP address provided in an API to the SCS/AS. - References to the extenal identifier are removed. The reason is that the PCC framework in stage 3 defines that if the UE IP address is provided it is used for session binding in the PCRF. - Communication fauilure is extended to include release codes for untrusted WLAN as well.","28","6.6","Monitoring Enhancements (MONTE)",12870,"Revised","2015-06-02T14:42:16.707","2015-06-02T15:18:50.173","S2-151749","S2-152078","Rel-13","23.682","13.1.0","MONTE","0093","5","B",null,"","","","",""]
["S2-151979","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent","Shabnam Sultana",21207,"CR","","","Summary of change: Changes according to conclusions in the FS_HLCOM study TR 23.709.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14530,"Revised","2015-06-02T14:42:16.893","2015-06-02T15:18:51.170","S2-151498","S2-152021","Rel-13","23.060","13.2.0","TEI13","1965","1","B",null,"","","","",""]
["S2-151980","HLcom solution reusing Monitoring Event 'UE Reachability' realization","LG Electronics","Jinsook Ryu",39022,"CR","","","Summary of change: The procedure for 'Using Monitoring Event - UE Reachability' in TR 23.709 is proposed to be reflected to this spec.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14570,"Revised","2015-06-02T14:42:17.063","2015-06-02T15:18:52.137","S2-151538","S2-152022","Rel-13","23.682","13.1.0","HLcom","0108","1","B",null,"","","","",""]
["S2-151981","HLcom solution Using Monitoring Event 'Availability after DDN Failure'","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Mike Dolan",1692,"CR","","","Summary of change: Soution 4 in TR 23.709 'Availability Notification after DDN Failure' is added to TS 23.682.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14600,"Revised","2015-06-02T14:42:17.237","2015-06-02T15:18:53.293","S2-151619","S2-152023","Rel-13","23.682","13.1.0","HLcom","0115","1","B",null,"","","","",""]
["S2-151982","Coversheet sending TR 23.709 for approval","Ericsson","Shabnam Sultana",21207,"TS or TR","","","Coversheet sending TR 23.709 for approval","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",0,"Revised","2015-06-02T14:42:17.423","2015-06-02T15:18:54.307","S2-151493","S2-152024","Rel-13","23.709","1.2.0","FS_HLcom","","","","","","","","",""]
["S2-151983","Update and Evaluation of extended C-DRX issues 2 and 3","Qualcomm Incorporated","Miguel Griot",43100,"pCR","","","Evaluates the different solutions for extended C-DRX issues 2 and 3","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15590,"Revised","2015-06-02T14:42:17.470","2015-06-02T15:18:55.197","S2-151683","S2-152104","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151984","Overall conclusion","Qualcomm Incorporated","Miguel Griot",43100,"pCR","","","Proposes an overall conclusion of feasibility","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15620,"Revised","2015-06-02T14:42:17.500","2015-06-02T15:18:56.240","S2-151684","S2-152105","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151985","Cover sheet for FS_eDRX","Qualcomm Incorporated","Miguel Griot",43100,"TS or TR","","","Proposed cover sheet for completion of TR 23.770","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",0,"Revised","2015-06-02T14:42:17.517","2015-06-02T15:18:57.147","S2-151688","S2-152106","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-151986","Correction of specification of Group Call suspension","Vodafone","Maurice Pope",648,"CR","","","Summary of change: Modification of section 5.4 to correct the MBMS suspension mechanism and not to refer to section 5.3.3.3, as the UE should not stop listening to MBMS channels.","13","5.1","3GPP Packet Access Maintenance",10820,"Revised","2015-06-02T14:42:17.563","2015-06-02T15:18:58.160","S2-151716","S2-151987","Rel-12","23.468","12.4.0","GCSE_LTE-MBMS_CM","0063","1","F",null,"","","","",""]
["S2-151987","Correction of specification of Group Call suspension","Vodafone","Maurice Pope",648,"CR","","","Summary of change: Modification of section 5.4 to correct the MBMS suspension mechanism and not to refer to section 5.3.3.3, as the UE should not stop listening to MBMS channels.","13","5.1","3GPP Packet Access Maintenance",10830,"Agreed","2015-06-02T14:45:43.470","2015-06-02T15:18:59.157","S2-151986","","Rel-12","23.468","12.4.0","GCSE_LTE-MBMS_CM","0063","2","F","SP-150227","","","","",""]
["S2-151988","Correction of specification of Group Call suspension","Vodafone","Maurice Pope",648,"CR","","","Rel-13 mirror CR: Summary of change: Modification of section 5.4 to correct the MBMS suspension mechanism and not to refer to section 5.3.3.3, as the UE should not stop listening to MBMS channels.","13","5.1","3GPP Packet Access Maintenance",10850,"Agreed","2015-06-02T14:45:43.673","2015-06-02T15:19:00.187","S2-151717","","Rel-13","23.468","13.0.0","GCSE_LTE-MBMS_CM","0064","1","A","SP-150227","","","","",""]
["S2-151989","Clarification on service authorisation procedure based on location","ZTE, ZTE Mobile","Jinguo Zhu",32987,"CR","","","Summary of change: It is clarfied that the authorisation info provided to the UE applies to the serving PLMN which is obtained from the HSS.","13","5.1","3GPP Packet Access Maintenance",10500,"Agreed","2015-06-02T14:45:43.830","2015-06-02T15:19:01.187","S2-151892","","Rel-12","23.303","12.4.0","ProSe","0173","2","F","SP-150226","","","","",""]
["S2-151990","[DRAFT] Reply LS on service authorisation procedure based on the location","SA WG2","Jinguo Zhu",32987,"LS out","","","To: CT WG1","13","5.1","3GPP Packet Access Maintenance",10460,"Revised","2015-06-02T14:45:44","2015-06-02T15:19:02.090","S2-151891","S2-152063","Rel-12","","","","","","","","S2-151442","CT WG1","-"]
["S2-151991","conclusion for ProSe UE-Network Relays","Samsung","Youngkyo Baek",46395,"pCR","","","In this contribution we propose to solve the remaining issues for ProSe UE-to-Network relay and conclude the study phase conditionally.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14050,"Approved","2015-06-02T14:45:44.017","2015-06-02T15:19:02.107","S2-151737","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151992","conclusion for one-to-one communication","Samsung","Youngkyo Baek",46395,"pCR","","","In this contribution we propose to solve the remaining issues for ProSe one-to-one communication and conclude the study phase at least for SA WG2 work scope.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14100,"Revised","2015-06-02T14:45:44.033","2015-06-02T15:19:03.027","S2-151734","S2-152000","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-151993","FMSS way forward","FMSS session","Ali-Amine Mouafik",44938,"pCR","","","This paper proposes a way forward for FMSS","33","6.13","Flexible Mobile Service Steering (FMSS)",14690,"Revised","2015-06-02T14:45:44.063","2015-06-02T15:19:03.947","S2-151934","S2-151994","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151994","FMSS way forward","FMSS session","Ali-Amine Mouafik",44938,"pCR","","","This paper proposes a way forward for FMSS","33","6.13","Flexible Mobile Service Steering (FMSS)",14700,"Revised","2015-06-02T14:49:17.163","2015-06-02T15:19:04.867","S2-151993","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-151995","Group specific NAS Level congestion control for multiple APNs","NTT DOCOMO","SRISAKUL THAKOLSRI",42550,"CR","","","Summary of change: It is proposed that the MME sends a NAS ESM message type that allows the UE belonging to a particular group to be blocked to stop sending a NAS ESM requests for all APNs.","29","6.7","Group based Enhancements (GROUPE)",12920,"Revised","2015-06-02T14:49:17.177","2015-06-02T15:19:05.897","S2-151881","S2-152079","Rel-13","23.401","13.2.0","GROUPE","2866","2","B",null,"","","","",""]
["S2-151996","Group specific NAS level congestion control for multiple APNs","NTT DOCOMO","SRISAKUL THAKOLSRI",42550,"CR","","","Summary of change: It is proposed that the SGSN sends a NAS SM message type that allows the MS belonging to a particular group to be blocked to stop sending a NAS SM requests for all APNs.","29","6.7","Group based Enhancements (GROUPE)",12960,"Revised","2015-06-02T14:49:17.367","2015-06-02T15:19:06.897","S2-151882","S2-152080","Rel-13","23.060","13.2.0","GROUPE","1967","2","B",null,"","","","",""]
["S2-151997","Request for specification of Dedicated Core Network (DECOR) feature","SA WG2","Daisuke Fujishima",58629,"LS out","","","Ask CT WG4 and RAN WG3 to initiate the specification of DECOR feature.","25","6.3","Dedicated Core Networks (DECOR)",11670,"Approved","2015-06-02T14:49:17.553","2015-06-02T15:19:07.830","S2-151792","","Rel-13","","","","","","","",null,"CT WG4, RAN WG3","TSG RAN"]
["S2-151998","Work Item Exception for ProSe","Qualcomm Incorporated (Rapporteur)","Haris Zisimopoulos",41602,"other","","","Exception sheet for eProSe-EXT","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13490,"Approved","2015-06-02T14:49:17.567","2015-06-02T15:19:07.847","S2-151808","","Rel-13","","","","","","","","","","","",""]
["S2-151999","TMGI and ECGI advertisement","Qualcomm Incorporated, Alcatel Lucent","Haris Zisimopoulos",41602,"pCR","","","This paper proposes to use PC5-D discovery for ProSe UE-Network Relay TMGI and ECGI advertisement.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",13940,"Approved","2015-06-02T14:49:17.583","2015-06-02T15:19:07.847","S2-151814","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-152000","conclusion for one-to-one communication","Samsung","Youngkyo Baek",46395,"pCR","","","In this contribution we propose to solve the remaining issues for ProSe one-to-one communication and conclude the study phase at least for SA WG2 work scope.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14110,"Approved","2015-06-02T14:49:17.617","2015-06-02T15:19:08.720","S2-151992","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-152001","Restricted ProSe Direct Discovery Model A procedures","Qualcomm Incorporated, ZTE, Telecom Italia, Huawei","Haris Zisimopoulos",41602,"CR","","","Summary of change: Adding the introductions and procedure details for restricted ProSe Direct Discovery Model A procedures.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14300,"Agreed","2015-06-02T14:49:17.630","2015-06-02T15:19:09.750","S2-151801","","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0168","2","B","SP-150233","","","","",""]
["S2-152002","Restricted ProSe Direct Discovery Model A Using on demand Announcing","Huawei, HiSilicon, Telecom Italia","Runze Zhou",60945,"CR","","","Summary of change: Adding the introductions and procedure details for Restricted ProSe Direct Discovery with on demand announcement.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14410,"Agreed","2015-06-02T14:49:17.817","2015-06-02T15:19:10.733","S2-151805","","Rel-13","23.303","12.4.0","eProSe-Ext-SA2","0175","2","B","SP-150233","","","","",""]
["S2-152003","UE-to-Network Relay selection and connection establishment","Qualcomm Incorporated","Haris Zisimopoulos",41602,"pCR","","","This contribution proposed the principles for the UE-to-Network Relay selection for ProSe.","31","6.10","Extended Proximity-based Services TR Phase (eProSe-Ext-SA2TR)",14010,"Approved","2015-06-02T14:49:17.973","2015-06-02T15:19:11.637","S2-151797","","Rel-13","23.713","1.3.0","eProSe-Ext-SA2TR","","","","","","","","",""]
["S2-152004","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16560,"Withdrawn","2015-06-02T14:49:17.990",null,"","","","","","","","","","","","","","",""]
["S2-152005","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16570,"Withdrawn","2015-06-02T14:49:18.007",null,"","","","","","","","","","","","","","",""]
["S2-152006","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16580,"Withdrawn","2015-06-02T14:49:18.020",null,"","","","","","","","","","","","","","",""]
["S2-152007","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16590,"Withdrawn","2015-06-02T14:49:18.020",null,"","","","","","","","","","","","","","",""]
["S2-152008","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16600,"Withdrawn","2015-06-02T14:49:18.037",null,"","","","","","","","","","","","","","",""]
["S2-152009","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16610,"Withdrawn","2015-06-02T14:49:18.050",null,"","","","","","","","","","","","","","",""]
["S2-152010","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16620,"Withdrawn","2015-06-02T14:49:18.050",null,"","","","","","","","","","","","","","",""]
["S2-152011","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16630,"Withdrawn","2015-06-02T14:49:18.083",null,"","","","","","","","","","","","","","",""]
["S2-152012","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16640,"Withdrawn","2015-06-02T14:49:18.083",null,"","","","","","","","","","","","","","",""]
["S2-152013","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16650,"Withdrawn","2015-06-02T14:49:18.097",null,"","","","","","","","","","","","","","",""]
["S2-152014","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16660,"Withdrawn","2015-06-02T14:49:18.113",null,"","","","","","","","","","","","","","",""]
["S2-152015","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16670,"Withdrawn","2015-06-02T14:49:18.130",null,"","","","","","","","","","","","","","",""]
["S2-152016","Reserved for Erik's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16680,"Withdrawn","2015-06-02T14:49:18.147",null,"","","","","","","","","","","","","","",""]
["S2-152017","Clarification of Group specific NAS Level congestion control","Huawei","Runze Zhou",60945,"CR","","","Summary of change: Remove 'same APN information is sent to the UE in the rejection message'.","29","6.7","Group based Enhancements (GROUPE)",13020,"Agreed","2015-06-02T14:49:18.147","2015-06-02T15:19:12.667","S2-151884","","Rel-13","23.060","13.2.0","GROUPE","1971","2","F","SP-150237","","","","",""]
["S2-152018","Group message delivery function and procedure","KPN, TNO, ZTE, Huawei, Hisilicon, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Samsung, Ericsson","Toon Norp",8605,"CR","","","Summary of change: High level description for group messge delivery function and delivery procedures is specified. Rev5: Add option to add option to add randomization of the response time information.","29","6.7","Group based Enhancements (GROUPE)",13050,"Agreed","2015-06-02T14:49:18.333","2015-06-02T15:19:13.680","S2-151885","","Rel-13","23.682","13.1.0","GROUPE","0094","6","B","SP-150237","","","","",""]
["S2-152019","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent","Shabnam Sultana",21207,"CR","","","Summary of change: Introduced description of the functions for High latency communication.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14460,"Revised","2015-06-02T14:49:18.503","2015-06-02T15:19:14.867","S2-151905","S2-152096","Rel-13","23.682","13.1.0","TEI13","0106","2","B",null,"","","","",""]
["S2-152020","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent","Shabnam Sultana",21207,"CR","","","Summary of change: Changes according to conclusions in the FS_HLCOM study TR 23.709.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14500,"Revised","2015-06-02T14:49:18.660","2015-06-02T15:19:15.880","S2-151906","S2-152097","Rel-13","23.401","13.2.0","TEI13","2862","2","B",null,"","","","",""]
["S2-152021","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent","Shabnam Sultana",21207,"CR","","","Summary of change: Changes according to conclusions in the FS_HLCOM study TR 23.709.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14540,"Revised","2015-06-02T14:49:18.830","2015-06-02T15:19:16.897","S2-151979","S2-152098","Rel-13","23.060","13.2.0","TEI13","1965","2","B",null,"","","","",""]
["S2-152022","HLcom solution reusing Monitoring Event 'UE Reachability' realization","LG Electronics","Jinsook Ryu",39022,"CR","","","Summary of change: The procedure for 'Using Monitoring Event - UE Reachability' in TR 23.709 is proposed to be reflected to this spec.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14580,"Agreed","2015-06-02T14:49:18.987","2015-06-02T15:19:17.923","S2-151980","","Rel-13","23.682","13.1.0","HLcom","0108","2","B","SP-150238","","","","",""]
["S2-152023","HLcom solution Using Monitoring Event 'Availability after DDN Failure'","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Mike Dolan",1692,"CR","","","Summary of change: Soution 4 in TR 23.709 'Availability Notification after DDN Failure' is added to TS 23.682.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14610,"Revised","2015-06-02T14:49:19.143","2015-06-02T15:19:19.237","S2-151981","S2-152099","Rel-13","23.682","13.1.0","HLcom","0115","2","B",null,"","","","",""]
["S2-152024","Coversheet sending TR 23.709 for approval","Ericsson","Shabnam Sultana",21207,"TS or TR","","","Coversheet sending TR 23.709 for approval","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14660,"Approved","2015-06-02T14:49:19.300","2015-06-02T15:19:20.140","S2-151982","","Rel-13","23.709","1.2.0","FS_HLcom","","","","","","","","",""]
["S2-152025","GTP-C re-transmissions","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution updates a solution for GTP-C re-transmissions and provides an evaluation of the two available solutions","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15470,"Approved","2015-06-02T14:49:19.347","2015-06-02T15:19:21.043","S2-151924","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-152026","MT SMS for Extended DRX","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution provides a solution for handling MT SMS for extended C-DRX","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15520,"Revised","2015-06-02T14:49:19.363","2015-06-02T15:19:21.950","S2-151926","S2-152103","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-152027","On the e-CDRX period","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, LG Electronics, Huawei, Qualcomm Inc.","Alessio Casati",13542,"pCR","","","This paper addresses the need to identify the expected range of the e-CDRX before we move to normative phase, in order to have a stable selection criterion for solutions.","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15560,"Withdrawn","2015-06-02T14:49:19.377",null,"S2-151932","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-152028","Introducing SCEF and RCAF Reference Point","China Mobile","Aihua Li",58162,"CR","","","Summary of change: Add description of new reference points Ns(RCAF- SCEF) that is to be introduced in TS 23.682 as part of AESE feature.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12200,"Agreed","2015-06-02T14:49:19.410","2015-06-02T15:19:23.867","S2-151910","","Rel-13","23.002","13.1.0","AESE","0284","2","B","SP-150235","","","","",""]
["S2-152029","Implementing AESE Solution on providing predictable communication patterns of a UE to the MME","NEC, CATT, Samsung","Andreas Kunz",35384,"CR","","","Summary of change: Add functional description and information flow for providing communication pattern parameters to the MME via HSS.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12240,"Revised","2015-06-02T14:49:19.580","2015-06-02T15:19:24.883","S2-151911","S2-152071","Rel-13","23.682","13.1.0","AESE","0113","2","B",null,"","","","",""]
["S2-152030","HSS and MME updates for AESE 3GPP resource optimizations based on providing predictable communication patterns of a UE to the MME","NEC, CATT, Intel, Ericsson","Andreas Kunz",35384,"CR","","","Summary of change: Updates to the HSS and MME for the AESE solution on 3GPP resource optimizations based on providing predictable communication patterns of a UEto the MME.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12280,"Agreed","2015-06-02T14:49:19.767","2015-06-02T15:19:25.850","S2-151912","","Rel-13","23.401","13.2.0","AESE","2872","2","B","SP-150235","","","","",""]
["S2-152031","Cover Sheet for TR 23.708 for Approval at TSG SA","Intel","Puneet Jain",36283,"TS or TR","","","Proposes a cover page for submitting TR 23.708 v1.2.0 to SA#68 plenary for Approval","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12400,"Approved","2015-06-02T14:49:19.957","2015-06-02T15:19:26.740","S2-151944","","Rel-13","23.708","1.1.0","AESE","","","","","","","","",""]
["S2-152032","LS on 3GPP Rel-13 MTC features for service capability exposure","SA WG2","Puneet Jain",36283,"LS out","","","LS to GSMA, OMA, oneM2M on Rel-13 MTC feature","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12430,"Approved","2015-06-02T14:49:20.033","2015-06-02T15:19:27.660","S2-151945","","Rel-13","","","","","","","",null,"GSMA, OMA, oneM2M","TSG SA, TSG CT"]
["S2-152033","Change the chargeable party at the session set-up or during the session","Intel","Puneet Jain",36283,"CR","","","This provides description of change the chargeable party at the session set-up or during the session","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12470,"Revised","2015-06-02T14:49:20.047","2015-06-02T15:19:27.767","S2-151942","S2-152074","Rel-13","23.682","13.1.0","AESE","0118","2","B",null,"","","","",""]
["S2-152034","Enhancing roaming architecture for Service Exposure","Ericsson, AT&T, Nokia Networks","Shabnam Sultana",21207,"CR","","","Summary of change: Introduce a lightweight proxy to aggregate communication with external parties.","28","6.6","Monitoring Enhancements (MONTE)",12650,"Revised","2015-06-02T14:49:20.220","2015-06-02T15:19:28.750","S2-151946","S2-152076","Rel-13","23.682","13.1.0","AESE, MONTE","0107","2","B",null,"","","","",""]
["S2-152035","Support for Monitoring Events","Intel, Cisco","Maulik Vaidya",44517,"CR","","","Summary of change: High level description for Monitoring Events feature. Support for Gn/Gp SGSN is clarified.","28","6.6","Monitoring Enhancements (MONTE)",12710,"Agreed","2015-06-02T14:49:20.390","2015-06-02T15:19:30.497","S2-151903","","Rel-13","23.060","13.2.0","MONTE","1961","5","B","SP-150236","","","","",""]
["S2-152036","Introduction of Charging Principles for Monitoring Events feature","Cisco","Maulik Vaidya",44517,"CR","","","Summary of change: Based on agreeements in S2-151455, high-level charging principles to be used for Monitoring Events feature are added.","28","6.6","Monitoring Enhancements (MONTE)",12790,"Agreed","2015-06-02T14:49:20.563","2015-06-02T15:19:31.480","S2-151975","","Rel-13","23.682","13.1.0","MONTE","0104","2","B","SP-150236","","","","",""]
["S2-152037","Monitoring event configuration in the HSS and MME","Samsung","Sung Hwan Won",46717,"CR","","","Summary of change: Monitoring Event Configuration Container is added in the HSS data/MME MM contexts.","28","6.6","Monitoring Enhancements (MONTE)",12820,"Agreed","2015-06-02T14:49:20.720","2015-06-02T15:19:32.510","S2-151976","","Rel-13","23.401","13.2.0","MONTE","2871","2","B","SP-150236","","","","",""]
["S2-152038","Monitoring event configuration in the HSS and SGSN","Samsung","Sung Hwan Won",46717,"CR","","","Summary of change: Monitoring Event Configuration Container is added in the HSS data/SGSN MM contexts.","28","6.6","Monitoring Enhancements (MONTE)",12850,"Agreed","2015-06-02T14:49:20.890","2015-06-02T15:19:33.540","S2-151977","","Rel-13","23.060","13.2.0","MONTE","1968","2","B","SP-150236","","","","",""]
["S2-152039","Cover Sheet for TR 23.797 for Information and Approval at TSG SA","FS_IOPS_St2 Rapporteur (General Dynamics UK Ltd.)","Philip Young",27298,"TS or TR","","","This contribution proposes a cover page for submitting TR 23.797 to SA plenary for Information and Approval","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15830,"Approved","2015-06-02T14:49:21.047","2015-06-02T15:19:34.413","S2-151930","","Rel-13","23.797","0.1.0","FS_IOPS_St2","","","","","","","","",""]
["S2-152040","LS on progress of IOPS in SA WG2 and security study dependencies","SA WG2","Philip Young",27298,"LS out","","","To: SA WG3","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15850,"Approved","2015-06-02T14:49:21.110","2015-06-02T15:19:35.287","S2-151931","","Rel-13","","","","","","","",null,"SA WG3","-"]
["S2-152041","Detailed description for informing about potential network issues","Huawei, HiSilicon, China Mobile, Cisco","Mirko Schramm",23396,"CR","","","Summary of change: It is proposed to document the detailed functional description for informing 3rd party about potential network issues.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12170,"Agreed","2015-06-02T14:49:21.127","2015-06-02T15:19:35.397","S2-151908","","Rel-13","23.682","13.1.0","AESE","0116","2","B","SP-150235","","","","",""]
["S2-152042","Aspects of metadata transfer and application reporting support for TDF/PCEF","Allot Communications, Cisco, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Comverse, SPRINT, Openet Telecom, Sandvine Incorporated","Alla Goldner",42718,"pCR","","","This contribution addresses aspects of metadata transfer and of application reporting for traffic steering policy generation for the Sd/Gx based solutions.","33","6.13","Flexible Mobile Service Steering (FMSS)",14770,"Approved","2015-06-02T14:49:21.297","2015-06-02T15:19:36.270","S2-151898","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152043","Updates to St based architecture solution","Ericsson, AT&T","Shabnam Sultana",21207,"pCR","","","Proposes updates to the solution based on St interface in order to resolve open issues and to clarify the relation with IETF/ONF architectures.","33","6.13","Flexible Mobile Service Steering (FMSS)",14820,"Approved","2015-06-02T14:49:21.327","2015-06-02T15:19:37.160","S2-151900","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152044","Address metadata report related Editor's notes for St based solution","China Telecom","Jinyan Li",46923,"pCR","","","This contribution intends to resolve the metadata reporting related editor's note for the St based solutions.","33","6.13","Flexible Mobile Service Steering (FMSS)",14850,"Approved","2015-06-02T14:49:21.343","2015-06-02T15:19:38.050","S2-151935","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152045","Details on how to handle report of changes of metadata over St","Ericsson","Shabnam Sultana",21207,"pCR","","","This paper proposes to remove Editors note on metadaa reporting over St interface.","33","6.13","Flexible Mobile Service Steering (FMSS)",14880,"Approved","2015-06-02T14:49:21.373","2015-06-02T15:19:38.953","S2-151936","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152046","Possible Solutions for Metadata Transferring","Huawei, HiSilicon","Shufeng Shi",56675,"pCR","","","This contribution proposes serveral possible solutions for metadata transferring.","33","6.13","Flexible Mobile Service Steering (FMSS)",14930,"Approved","2015-06-02T14:49:21.407","2015-06-02T15:19:39.857","S2-151939","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152047","Conclusion of FMSS","China Mobile, Broadcom, CATR, China Telecom, China Unicom","Tao Sun",54129,"pCR","","","This paper propose a conclusion for FMSS in R-13","33","6.13","Flexible Mobile Service Steering (FMSS)",15020,"Revised","2015-06-02T14:49:21.420","2015-06-02T15:19:40.763","S2-151934","S2-152048","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152048","Conclusion of FMSS","China Mobile, Broadcom, CATR, China Telecom, China Unicom","Tao Sun",54129,"pCR","","","This paper propose a conclusion for FMSS in R-13","33","6.13","Flexible Mobile Service Steering (FMSS)",15030,"Revised","2015-06-02T14:52:16.830","2015-06-02T15:19:41.667","S2-152047","S2-152094","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152049","SID on VoLTE with S8 Home Routing","NTT DOCOMO","Irfan Ali",50390,"WID","","","Proposes a study item to identify the specification changes needed to enable S8HR as a routing architecture for VoLTE","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10210,"Revised","2015-06-02T14:52:16.847","2015-06-02T15:19:42.573","S2-151973","S2-152061","Rel-4","","","","","","","","","","","",""]
["S2-152050","Reserved for Frank's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16850,"Withdrawn","2015-06-02T14:52:16.877",null,"","","","","","","","","","","","","","",""]
["S2-152051","Reserved for Frank's parallel sessions","-","Maurice Pope",648,"other","","","-","47","99","Reserved and Withdrawn documents",16860,"Withdrawn","2015-06-02T14:52:16.877",null,"","","","","","","","","","","","","","",""]
["S2-152052","Exception for HLCOM normative work","Ericsson","Shabnam Sultana",21207,"other","","","Exception for HLCOM normative work (if it does not get finalized in SA WG2#109)","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14680,"Approved","2015-06-02T14:52:16.893","2015-06-02T15:19:42.587","S2-151495","","Rel-13","","","","","","","","","","","",""]
["S2-152053","FMSS Rel-13 Exception Request","CHINA MOBILE","Tao Sun",54129,"other","","","Rel-13 Exception Request for FMSS","33","6.13","Flexible Mobile Service Steering (FMSS)",15120,"Revised","2015-06-02T14:52:16.893","2015-06-02T15:19:42.603","S2-151643","S2-152128","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152054","Rel-13 Work Item Exception for MBMS_enh","Nokia Networks","Rainer Liebhart",13470,"other","","","Exception sheet for the new Rel-13 WID on MBMS Enhancements (S2-151658).","34","6.14","MBMS Enhancements (MBMS_enh)",15320,"Noted","2015-06-02T14:52:16.907","2015-06-02T15:19:43.493","S2-151691","","Rel-13","","","","","","","","","","","",""]
["S2-152055","3GPP Work Item Exception for eDRX","Qualcomm Incorporated","Miguel Griot",43100,"other","","","Work item exception sheet for new proposed WID eDRX","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15680,"Approved","2015-06-02T14:52:16.923","2015-06-02T15:19:43.540","S2-151687","","Rel-13","","","","","","","","","","","",""]
["S2-152056","Draft Rel-13 Work Item Exception for IOPS","FS_IOPS_St2 Rapporteur (General Dynamics UK Ltd.)","Philip Young",27298,"other","","","This contribution proposes a draft Exception Sheet to cover normative IOPS work","36","6.16","Feasibility study on IOPS (FS_IOPS_St2)",15870,"Approved","2015-06-02T14:52:16.940","2015-06-02T15:19:43.587","S2-151594","","Rel-13","","","","","","","","","","","",""]
["S2-152057","Rel-13 Work Item Exception for eWebRTCi","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Rel-13 Work Item Exception for eWebRTCi","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13430,"Revised","2015-06-02T14:52:16.970","2015-06-02T15:19:43.617","S2-151855","S2-152127","Rel-13","","","","","","","","","","","",""]
["S2-152058","Rel-13 Work Item Exception for SEW1","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Rel-13 Work Item Exception for SEW1. This is the normative WID spinned-off from the phase 1 of FS_SEW. may have to be moved to AI 7.2.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16330,"Revised","2015-06-02T14:52:16.987","2015-06-02T15:19:43.667","S2-151865","S2-152130","Rel-13","","","","","","","","","","","",""]
["S2-152059","NBIFOM Rel-13 Exception Request","ZTE","Tricci So",44974,"other","","","Rel-13 Exception Request for NBIFOM","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",12030,"Revised","2015-06-02T14:52:17","2015-06-02T15:19:43.697","S2-151856","S2-152121","Rel-13","","","","","","","","","","","",""]
["S2-152060","Work Planning work sheet","Samsung","Frank Mademann",6821,"other","","","Updated Status of SA WG2 Work Items","43","7.2","Review of the Work Plan",16830,"Noted","2015-06-02T14:52:17.017","2015-06-02T15:19:43.743","S2-151919","","","","","","","","","","","","","",""]
["S2-152061","SID on VoLTE with S8 Home Routing","NTT DOCOMO","Irfan Ali",50390,"WID","","","Proposes a study item to identify the specification changes needed to enable S8HR as a routing architecture for VoLTE","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10220,"Approved","2015-06-02T14:54:32.507","2015-06-02T15:19:43.773","S2-152049","","Rel-4","","","","","","","","","","","",""]
["S2-152062","Reply LS on VoLTE Roaming Architecture","SA WG2","Motohiro Abe",57779,"LS out","","","Replies to two GSMA LS (S2-151434 and S2-151440) on VoLTE Roaming Architecture. SA WG2 has approved SID on VoLTE with S8HR.","7","4.2","LS (S2-151434, S2-151440) on VoLTE Roaming, Replies and related SID proposal",10250,"Revised","2015-06-02T14:54:32.520","2015-06-02T15:19:43.807","S2-151974","","Rel-4","","","","","","","","S2-151434","GSMA PMSC, GSMA NG","TSG SA, TSG CT, CT WG3, SA WG3-LI, SA WG5, SA WG3"]
["S2-152063","Reply LS on service authorisation procedure based on the location","SA WG2","Jinguo Zhu",32987,"LS out","","","To: CT WG1. Attachment: S2-151989","13","5.1","3GPP Packet Access Maintenance",10470,"Approved","2015-06-02T14:54:32.537","2015-06-02T15:19:43.837","S2-151990","","Rel-12","","","","","","","","S2-151442","CT WG1","-"]
["S2-152064","Reply LS on network feature support for ProSe Discovery","SA WG2","Haris Zisimopoulos",41602,"LS out","","","Provides answer to CT WG1 LS on network feature support for ProSe","13","5.1","3GPP Packet Access Maintenance",10550,"Approved","2015-06-02T14:54:32.550","2015-06-02T15:19:43.853","S2-151894","","Rel-12","","","","","","","","S2-151443","CT WG1","SA WG1, RAN WG2"]
["S2-152065","Correction of UE identities used between ProSe Function for service authorization","Qualcomm Incorporated","Haris Zisimopoulos",41602,"CR","","","Summary of change: Update the procedure in 5.2.2.4 to allow either IMSI or MSISDN to be used as the UE identifier.","13","5.1","3GPP Packet Access Maintenance",10610,"Agreed","2015-06-02T14:54:32.567","2015-06-02T15:19:43.977","S2-151895","","Rel-12","23.303","12.4.0","ProSe","0170","2","F","SP-150226","","","","",""]
["S2-152066","LS on UE identity used between ProSe Functions for ProSe Service Authorization","SA WG2","Haris Zisimopoulos",41602,"LS out","","","Provides answer to CT WG4 LS on UE Identify in ProSe Authorisation procedures","13","5.1","3GPP Packet Access Maintenance",10640,"Approved","2015-06-02T14:54:32.740","2015-06-02T15:19:44.867","S2-151582","","Rel-12","","","","","","","","S2-151451","CT WG4","CT WG1, SA WG5"]
["S2-152067","Correct FlowID per agreement with CT WG3","Alcatel-Lucent, Nokia Networks, Samsung","Mike Dolan",1692,"CR","","","Summary of change: The FlowID is allocated in all cases by the BM-SC in the Activate MBMS Bearer procedure.","13","5.1","3GPP Packet Access Maintenance",10730,"Agreed","2015-06-02T14:54:32.753","2015-06-02T15:19:44.977","S2-151479","","Rel-12","23.468","12.4.0","GCSE_LTE","0058","1","F","SP-150227","","","","",""]
["S2-152068","Correct FlowID per agreement with CT WG3","Alcatel-Lucent, Nokia Networks, Samsung","Mike Dolan",1692,"CR","","","Rel-13 mirror CR: Summary of change: The FlowID is allocated in all cases by the BM-SC in the Activate MBMS Bearer procedure.","13","5.1","3GPP Packet Access Maintenance",10750,"Agreed","2015-06-02T14:54:32.910","2015-06-02T15:19:45.943","S2-151480","","Rel-13","23.468","13.0.0","GCSE_LTE","0059","1","A","SP-150227","","","","",""]
["S2-152069","LS on Flow ID supplied by GCS AS","SA WG2","Laurent Thiebaut",11066,"LS out","","","SA WG2 thanks CT WG3 for your LS on Flow ID supplied by GCS AS (S2-150712/C3-150446). SA WG2 reaffirms that there is an agreement with CT WG3 that the BM-SC shall be responsible for allocation of the Flow ID and that there is no predefined meaning. Therefore, SA WG2 have agreed CRxxxx to TS 23.468 for Rel-12 to allow only the BM-SC to allocate the Flow ID.","13","5.1","3GPP Packet Access Maintenance",10800,"Approved","2015-06-02T14:54:33.067","2015-06-02T15:19:46.833","S2-151478","","Rel-12","","","","","","","","S2-151437","CT WG3"]
["S2-152070","[DRAFT] LS on the risk of IMSI exposure at the SCEF","SA WG2","Laurent Thiebaut",11066,"LS out","","","SA WG2 thanks SA WG3 for your LS on the risk of IMSI exposure at the SCEF. SA WG2 notes that TS 23.682 v13.0 clause 4.2 says:The trust domain (see figure 4.2-2) cover entities that are protected by adequate network domain security. The entities and interfaces within the trust domain may all be within one operator's control, or some may be controlled by a trusted business partner which has a trust relationship with the operator e.g. another operator or a 3rd party. When not under the control of the PLMN operator, it is up to the PLMN operator to ensure that access to the PLMN operator's network from the SCEF is deployed in a manner consistent with security principles of the 3GPP network as outlined by SA WG3 security specifications.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12090,"Revised","2015-06-02T14:54:33.097","2015-06-02T15:19:46.863","S2-151914","S2-152123","Rel-13","","","","","","","","S2-151464","SA WG3"]
["S2-152071","Implementing AESE Solution on providing predictable communication patterns of a UE to the MME","NEC, CATT, Samsung, Intel, Ericsson","Andreas Kunz",35384,"CR","","","Summary of change: Add functional description and information flow for providing communication pattern parameters to the MME via HSS.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12250,"Agreed","2015-06-02T14:54:33.113","2015-06-02T15:19:46.973","S2-152029","","Rel-13","23.682","13.1.0","AESE","0113","3","B","SP-150235","","","","",""]
["S2-152072","Addition of resource management for background data transfer feature","NTT DOCOMO, Huawei, Hisilicon, Intel","Syed Husain",14749,"CR","","","Summary of change: This provides description of resource management for background data transfer.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12340,"Agreed","2015-06-02T14:54:33.270","2015-06-02T15:19:47.970","S2-151940","","Rel-13","23.682","13.1.0","AESE","0114","2","B","SP-150235","","","","",""]
["S2-152073","Resource management for background data transfer via Rx","Huawei, HiSilicon, NTT DOCOMO, Ericsson, Intel","Mirko Schramm",23396,"CR","","","Summary of change: It is proposed to document the detailed functional description of resource management for background data transfer via Rx.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12370,"Agreed","2015-06-02T14:54:33.427","2015-06-02T15:19:48.953","S2-151941","","Rel-13","23.203","13.3.0","AESE","0975","2","B","SP-150235","","","","",""]
["S2-152074","Change the chargeable party at the session set-up or during the session","Intel, Huawei, Alcatel-Lucent","Puneet Jain",36283,"CR","","","This provides description of change the chargeable party at the session set-up or during the session","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12480,"Agreed","2015-06-02T14:54:33.597","2015-06-02T15:19:49.937","S2-152033","","Rel-13","23.682","13.1.0","AESE","0118","3","B","SP-150235","","","","",""]
["S2-152075","Clarification on the overall  architecture related with SCEF","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"CR","","","Summary of change: Clarifies that the SCEF belongs to the HPLMN. Clarifies which southbound interfaces of the SCEF may correspond to raoming. Provides a high level description of the Authorization process for an API","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12510,"Revised","2015-06-02T14:54:33.753","2015-06-02T15:19:50.873","S2-151943","S2-152109","Rel-13","23.682","13.1.0","AESE","0119","2","C",null,"","","","",""]
["S2-152076","Enhancing roaming architecture for Service Exposure","Ericsson, AT&T, Nokia Networks","Shabnam Sultana",21207,"CR","","","Summary of change: Introduce a lightweight proxy to aggregate communication with external parties.","28","6.6","Monitoring Enhancements (MONTE)",12660,"Revised","2015-06-02T14:54:33.910","2015-06-02T15:19:51.840","S2-152034","S2-152110","Rel-13","23.682","13.1.0","AESE, MONTE","0107","3","B",null,"","","","",""]
["S2-152077","Introduction of monitoring procedures","Huawei, HiSilicon, Intel, Alcatel-Lucent, Cisco, LG Electronics, Ericsson, NEC","Frank Mademann",6821,"CR","","","Summary of change: The procedures for supporting monitoring configuration via MME/SGSN and via HSS are introduced. The procedure for reporting of Monitoring Events from the HSS or the MME/SGSN is also introduced.","28","6.6","Monitoring Enhancements (MONTE)",12740,"Agreed","2015-06-02T14:54:34.067","2015-06-02T15:19:53.587","S2-151904","","Rel-13","23.682","13.1.0","MONTE","0097","5","B","SP-150236","","","","",""]
["S2-152078","Monitoring via PCRF","Ericsson","Shabnam Sultana",21207,"CR","","","Summary of change: Reporting current user location and communication failure via PCRF as defined in 23.203. Clarifications are included in this version as follows: - A note is added to sub-clause 5.n.x.2 to clarify that the UE IP address is supposed not to be NAT'ed, the reason is that PCC framework is reused as currently defined that places the responsibility to provide the UE IP address known at the PCEF over Rx interface, the SCEF has no capabilities to translate the UE IP address provided in an API to the SCS/AS. - References to the extenal identifier are removed. The reason is that the PCC framework in stage 3 defines that if the UE IP address is provided it is used for session binding in the PCRF. - Communication fauilure is extended to include release codes for untrusted WLAN as well.","28","6.6","Monitoring Enhancements (MONTE)",12880,"Agreed","2015-06-02T14:54:34.220","2015-06-02T15:19:54.727","S2-151978","","Rel-13","23.682","13.1.0","MONTE","0093","6","B","SP-150236","","","","",""]
["S2-152079","Group specific NAS Level congestion control for multiple APNs","NTT DOCOMO","SRISAKUL THAKOLSRI",42550,"CR","","","Summary of change: It is proposed that the MME sends a NAS ESM message type that allows the UE belonging to a particular group to be blocked to stop sending a NAS ESM requests for all APNs.","29","6.7","Group based Enhancements (GROUPE)",12930,"Agreed","2015-06-02T14:54:34.393","2015-06-02T15:19:55.677","S2-151995","","Rel-13","23.401","13.2.0","GROUPE","2866","3","F","SP-150237","","","","",""]
["S2-152080","Group specific NAS level congestion control for multiple APNs","NTT DOCOMO","SRISAKUL THAKOLSRI",42550,"CR","","","Summary of change: It is proposed that the SGSN sends a NAS SM message type that allows the MS belonging to a particular group to be blocked to stop sending a NAS SM requests for all APNs.","29","6.7","Group based Enhancements (GROUPE)",12970,"Agreed","2015-06-02T14:54:34.547","2015-06-02T15:19:56.643","S2-151996","","Rel-13","23.060","13.2.0","GROUPE","1967","3","F","SP-150237","","","","",""]
["S2-152081","Reply to LS from SA WG4: Reply LS on TR 26.924 Study on improved end-to-end QoS handling","SA WG2","Belen Pancorbo",4022,"LS out","","","To: SA WG4. CC: CT WG1, CT WG3, CT WG4","21","6.1.2","Rel-13 PCC/QoS Maintenance",11120,"Approved","2015-06-02T14:54:34.703","2015-06-02T15:19:57.503","S2-151958","","Rel-13","","","","","","","","S2-151654","SA WG4","CT WG3, CT WG1, CT WG4, RAN WG2"]
["S2-152082","Reply LS on APN Usage in NSWO Rules","SA WG2","Stefano Faccin",42400,"LS out","","","To: CT WG1","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11320,"Approved","2015-06-02T14:54:34.720","2015-06-02T15:19:57.517","S2-151826","","","","","","","","","","S2-151447","CT WG1","-"]
["S2-152083","Session/bearer release cause over S2b","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Nicolas Drevon",16459,"CR","","","Summary of change: - An Untrusted WLAN Release cause is introduced over S2b. - It is also clarified for S2a and S2b that the PGW also stores the Release Cause in the CDRs (this is missing in the current specification).","22","6.1.3","Rel-13 Non-3GPP Access Maintenence",11380,"Agreed","2015-06-02T14:54:34.737","2015-06-02T15:19:57.627","S2-151828","","Rel-13","23.402","13.1.0","TEI13","1366","2","F","SP-150239","","","","",""]
["S2-152084","Proposed NBIFOM Technical Specification Skeleton","ZTE","Tricci So",44974,"other","","","This PCR is to propose the TS skeleton to be adopted and be used as the template to capture the NBIFOM Rel-13 normative text in the TR 23.861 Annex X in the interim until the designated NBIFOM TS is assigned.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",0,"Approved","2015-06-02T14:54:34.890","2015-06-02T15:19:58.500","S2-151955","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-152085","Text for TS section 5","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Broadcom Corporation, ZTE, Huawei, HiSilicon","Laurent Thiebaut",11066,"pCR","","","This contribution proposes text for section 5 of the future TS on NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11780,"Revised","2015-06-02T14:54:34.907","2015-06-02T15:19:59.467","S2-151869","S2-152111","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-152086","NBIFOM Call Flows - 3GPP initial & additional attach, IP flow mobility & routing rules mapping","ZTE, Alcatel-Lucent, Alcatel-Lucent Shanghai-Bell","Tricci So",44974,"pCR","","","This PCR is to propose normative text to NBIFOM call flows for procedures related to 3GPP access for initial and additional attach, IP flow mobility and routing rules mapping.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11860,"Approved","2015-06-02T14:54:34.937","2015-06-02T15:20:00.420","S2-151953","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-152087","NBIFOM Call Flows - Access Removal","ZTE","Tricci So",44974,"pCR","","","This PCR is to propose normative text to NBIFOM call flows for removing an access.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11900,"Revised","2015-06-02T14:54:34.953","2015-06-02T15:20:01.387","S2-151954","S2-152112","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-152088","Using RAN Rule in NBIFOM","Huawei, HiSilicon, ZTE","Runze Zhou",60945,"pCR","","","This contribution discusses using RAN Rule in NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11970,"Approved","2015-06-02T14:54:34.970","2015-06-02T15:20:02.277","S2-151956","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-152089","Revised NBIFOM WID for Rel-13","ZTE Corporation","Tricci So",44974,"WID","","","Revised NBIFOM WID to request for dedicated TS assignment to capture the normative procedures and also to update the conclusion date for the normative phase.","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16810,"Approved","2015-06-02T14:54:35","2015-06-02T15:20:03.167","S2-151879","","Rel-13","","","","","","","","","","","",""]
["S2-152090","Configuring AF application identifier value in PCRF to avoid SRVCC","ZTE","Zhendong Li",38521,"CR","","","Summary of change: If the operator wants to avoid SRVCC in WebRTC, the AF and PCRF should be configured with same specific AF application identifier used in PCC procedure to avoid QCI I bearer establishment.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13350,"Revised","2015-06-02T14:54:35.017","2015-06-02T15:20:03.273","S2-151851","S2-152091","Rel-13","23.203","13.3.0","eWebRTCi","0976","2","F",null,"","","","",""]
["S2-152091","Configuring AF application identifier value in PCRF to avoid SRVCC","ZTE, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Zhendong Li",38521,"CR","","","Summary of change: If the operator wants to avoid SRVCC in WebRTC, the AF and PCRF should be configured with same specific AF application identifier used in PCC procedure to avoid QCI I bearer establishment.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13360,"Agreed","2015-06-02T14:57:12.657","2015-06-02T15:20:04.287","S2-152090","","Rel-13","23.203","13.3.0","eWebRTCi","0976","3","F","SP-150232","","","","",""]
["S2-152092","Corrections to OMR-based e2e media transport solution","Orange","Antoine Mouquet",38438,"pCR","","","Corrections to the OMR-based e2e media transport solution, mainly considering that the eP-CSCF does not allocate a TrGW but an IMS-AGW.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13180,"Approved","2015-06-02T14:57:12.843","2015-06-02T15:20:05.210","S2-151723","","Rel-13","23.706","0.3.0","eWebRTCi","","","","","","","","",""]
["S2-152093","Presentation of 23.771 (FS_SEW) to SA","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Presentation of 23.771 (FS_SEW) to SA","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16270,"Approved","2015-06-02T14:57:12.877","2015-06-02T15:20:06.113","S2-151842","","Rel-13","","","","","","","","","","","",""]
["S2-152094","Conclusion of FMSS","China Mobile, Broadcom, CATR, China Telecom, China Unicom","Tao Sun",54129,"pCR","","","This paper propose a conclusion for FMSS in R-13","33","6.13","Flexible Mobile Service Steering (FMSS)",15040,"Approved","2015-06-02T14:57:12.890","2015-06-02T15:20:06.113","S2-152048","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152095","Cover sheet for TR 23.718 for presentation to TSG SA for information","China Mobile","Tao Sun",54129,"TS or TR","","","Cover sheet for TR 23.718 for presentation to TSG SA for information","33","6.13","Flexible Mobile Service Steering (FMSS)",15050,"Revised","2015-06-02T14:57:12.907","2015-06-02T15:20:07.017","","S2-152114","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152096","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent","Shabnam Sultana",21207,"CR","","","Summary of change: Introduced description of the functions for High latency communication.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14470,"Agreed","2015-06-02T14:57:12.953","2015-06-02T15:20:08","S2-152019","","Rel-13","23.682","13.1.0","HLcom","0106","3","B","SP-150238","","","","",""]
["S2-152097","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent, CATT","Shabnam Sultana",21207,"CR","","","Summary of change: Changes according to conclusions in the FS_HLCOM study TR 23.709.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14510,"Agreed","2015-06-02T14:57:13.140","2015-06-02T15:20:09","S2-152020","","Rel-13","23.401","13.2.0","HLcom","2862","3","B","SP-150238","","","","",""]
["S2-152098","Introducing functions for High latency communication","Ericsson, Alcatel-Lucent","Shabnam Sultana",21207,"CR","","","Summary of change: Changes according to conclusions in the FS_HLCOM study TR 23.709.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14550,"Agreed","2015-06-02T14:57:13.297","2015-06-02T15:20:10.013","S2-152021","","Rel-13","23.060","13.2.0","HLcom","1965","3","B","SP-150238","","","","",""]
["S2-152099","HLcom solution Using Monitoring Event 'Availability after DDN Failure'","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Mike Dolan",1692,"CR","","","Summary of change: Soution 4 in TR 23.709 'Availability Notification after DDN Failure' is added to TS 23.682.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14620,"Revised","2015-06-02T14:57:13.483","2015-06-02T15:20:10.997","S2-152023","S2-152115","Rel-13","23.682","13.1.0","HLcom","0115","3","B",null,"","","","",""]
["S2-152100","Proposed Solution B for Key Issue 1 using MBSFN Area Id and/or ECGI list","Motorola Solutions","Val Oprescu",14981,"pCR","","","This contribution proposes a solution for Key issue 1 for Rel-13 which preserves (from Rel-12) the capability of the Application/GCS AS to indicate (rather than rely on RAN-level guesses) which kind of bearer and exactly which area of distribution for the bearer is to be used. The proposal employs MBSFN Area Ids in lieu of service areas and SAIs, to request/modify service. ECGI lists can be used for SC-PTM.","34","6.14","MBMS Enhancements (MBMS_enh)",15190,"Approved","2015-06-02T14:57:13.670","2015-06-02T15:20:11.887","S2-151886","","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-152101","Proposed new Key Issue: 'MBMS Congestion' Mitigation for Rel-13","Motorola Solutions","Val Oprescu",14981,"pCR","","","Proposes the addition of the Key Issue to study for MBMS congestion management in Rel-13","34","6.14","MBMS Enhancements (MBMS_enh)",15230,"Revised","2015-06-02T14:57:13.687","2015-06-02T15:20:12.777","S2-151915","S2-152116","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-152102","Extended DRX in Idle","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution provides details to the solution 5.2.1 Paging coordination between CN and UE","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15390,"Approved","2015-06-02T14:57:13.700","2015-06-02T15:20:13.663","S2-151922","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-152103","MT SMS for Extended DRX","Ericsson","Shabnam Sultana",21207,"pCR","","","This contribution provides a solution for handling MT SMS for extended C-DRX","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15530,"Approved","2015-06-02T14:57:13.733","2015-06-02T15:20:14.537","S2-152026","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-152104","Update and Evaluation of extended C-DRX issues 2 and 3","Qualcomm Incorporated","Miguel Griot",43100,"pCR","","","Evaluates the different solutions for extended C-DRX issues 2 and 3","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15600,"Revised","2015-06-02T14:59:57.160","2015-06-02T15:20:15.443","S2-151983","S2-152129","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-152105","Overall conclusion","Qualcomm Incorporated","Miguel Griot",43100,"pCR","","","Proposes an overall conclusion of feasibility","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15630,"Approved","2015-06-02T14:59:57.177","2015-06-02T15:20:16.317","S2-151984","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-152106","Cover sheet for FS_eDRX","Qualcomm Incorporated","Miguel Griot",43100,"TS or TR","","","Proposed cover sheet for completion of TR 23.770","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15660,"Approved","2015-06-02T14:59:57.193","2015-06-02T15:20:17.190","S2-151985","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-152107","Introduce the Dedicated Core Network (DECOR) feature","NTT DOCOMO, Huawei, Ericsson, NEC, Samsung, TeliaSonera, AT&T","Irfan Ali",50390,"CR","","","Summary of change: Introduce the decor feature based on conclusions of TR 23.707","25","6.3","Dedicated Core Networks (DECOR)",11470,"Agreed","2015-06-02T14:59:57.270","2015-06-02T15:20:18.187","S2-151817","","Rel-13","23.401","13.2.0","DECOR","2837","11","B","SP-150234","","","","",""]
["S2-152108","Adding support for load re-balancing within DCN","Ericsson, TeliaSonera, AT&T, NTT DOCOMO, Huawei","Shabnam Sultana",21207,"CR","","","Summary of change: Describes load re-balancing using the NAS Message Redirection procedure within a DCN for E-UTRAN.","25","6.3","Dedicated Core Networks (DECOR)",11560,"Agreed","2015-06-02T14:59:57.473","2015-06-02T15:20:19.187","S2-151819","","Rel-13","23.401","13.2.0","DECOR","2864","3","B","SP-150234","","","","",""]
["S2-152109","Clarification on the overall architecture related with SCEF","Alcatel-Lucent","Laurent Thiebaut",11066,"CR","","","Summary of change: Clarifies that the SCEF belongs to the HPLMN. Clarifies which southbound interfaces of the SCEF may correspond to raoming. Provides a high level description of the Authorization process for an API","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12440,"Revised","2015-06-02T14:59:57.660","2015-06-02T15:20:20.170","S2-152075","S2-152124","Rel-13","23.682","13.1.0","AESE","0119","3","C",null,"","","","",""]
["S2-152110","Enhancing roaming architecture for Service Exposure","Ericsson, AT&T, Nokia Networks, Cisco, Intel","Shabnam Sultana",21207,"CR","","","Summary of change: Introduce a lightweight proxy to aggregate communication with external parties.","28","6.6","Monitoring Enhancements (MONTE)",12670,"Revised","2015-06-02T14:59:57.847","2015-06-02T15:20:21.200","S2-152076","S2-152125","Rel-13","23.682","13.1.0","AESE, MONTE","0107","4","B",null,"","","","",""]
["S2-152111","Text for TS section 5","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Broadcom Corporation, ZTE, Huawei, HiSilicon","Laurent Thiebaut",11066,"pCR","","","This contribution proposes text for section 5 of the future TS on NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11790,"Revised","2015-06-02T14:59:58.033","2015-06-02T15:20:22.853","S2-152085","S2-152119","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-152112","NBIFOM Call Flows - Access Removal","ZTE","Tricci So",44974,"pCR","","","This PCR is to propose normative text to NBIFOM call flows for removing an access.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11910,"Revised","2015-06-02T14:59:58.050","2015-06-02T15:20:23.743","S2-152087","S2-152120","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-152113","Supporting Class of Users","Nokia Networks","Martin Oettl",17230,"CR","","","Summary of change: Adding a NOTE which clarifies that the pool of identities granted towards a third party owning the WWSF may also be a wildcarded range of identities.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13280,"Revised","2015-06-02T14:59:58.067","2015-06-02T15:20:24.770","S2-151849","S2-152126","Rel-13","23.228","13.2.0","eWebRTCi","1134","2","B",null,"","","","",""]
["S2-152114","Cover sheet for TR 23.718 for presentation to TSG SA for information","China Mobile","Tao Sun",54129,"TS or TR","","","Cover sheet for TR 23.718 for presentation to TSG SA for information","33","6.13","Flexible Mobile Service Steering (FMSS)",15060,"Approved","2015-06-02T14:59:58.253","2015-06-02T15:20:25.723","S2-152095","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152115","HLcom soluton Using Monitoring Event 'Availability after DDN Failure'","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Mike Dolan",1692,"CR","","","Summary of change: Soution 4 in TR 23.709 'Availability Notification after DDN Failure' is added to TS 23.682.","32","6.12","Optimizations to Support High Latency Communications (FS_HLCom)",14630,"Agreed","2015-06-02T14:59:58.317","2015-06-02T15:20:26.707","S2-152099","","Rel-13","23.682","13.1.0","TEI13","0115","4","B","SP-150238","","","","",""]
["S2-152116","Proposed new Key Issue: 'MBMS Congestion' Mitigation for Rel-13","Motorola Solutions","Val Oprescu",14981,"pCR","","","Proposes the addition of the Key Issue to study for MBMS congestion management in Rel-13","34","6.14","MBMS Enhancements (MBMS_enh)",15240,"Approved","2015-06-02T14:59:58.470","2015-06-02T15:20:27.563","S2-152101","","Rel-13","23.741","0.2.0","MBMS_enh","","","","","","","","",""]
["S2-152118","SA WG2 Exception Sheet for MCPTT","U.S. Department of Commerce (SA WG2 MCPTT Rapporteur)","Randy Bloomfield",56665,"other","","","SA WG2 Exception sheet for the MCPTT feature.","24","6.2","Mission Critical Push to Talk over LTE (MCPTT)",11421,"Approved","2015-06-05T11:57:42.037","2015-06-05T11:55:28.597","S2-151731","","Rel-13","","","","","","","","","","","",""]
["S2-152119","Text for TS section 5","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Broadcom Corporation, ZTE, Huawei, HiSilicon","Laurent Thiebaut",11066,"pCR","","","This contribution proposes text for section 5 of the future TS on NBIFOM.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11791,"Approved","2015-06-05T11:57:42.053","2015-06-05T11:55:28.610","S2-152111","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-152120","NBIFOM Call Flows - Access Removal","ZTE","Tricci So",44974,"pCR","","","This PCR is to propose normative text to NBIFOM call flows for removing an access.","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",11911,"Approved","2015-06-05T11:57:42.087","2015-06-05T11:55:29.453","S2-152112","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-152121","NBIFOM Rel-13 Exception Request","ZTE","Tricci So",44974,"other","","","Rel-13 Exception Request for NBIFOM","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",12031,"Approved","2015-06-05T11:57:42.117","2015-06-05T11:55:30.310","S2-152059","","Rel-13","","","","","","","","","","","",""]
["S2-152122","NBIFOM TR 23.861 Cover Sheet for TR Conclusions","ZTE","Tricci So",44974,"TS or TR","","","NBIFOM Rel-13 study was concluded in SA WG2#108, this tdoc is to prepare the cover sheet to present the concluded NBIFOM TR 23.861 to SA#68 for approval","26","6.4","IP Flow Mobility support for S2a and S2b interfaces (NBIFOM)",12051,"Approved","2015-06-05T11:57:42.147","2015-06-05T11:55:30.327","S2-151857","","Rel-13","23.861","1.16.0","NBIFOM","","","","","","","","",""]
["S2-152123","[DRAFT] LS on the risk of IMSI exposure at the SCEF","SA WG2","Mike Dolan",1692,"LS out","","","SA WG2 thanks SA WG3 for your LS on the risk of IMSI exposure at the SCEF. SA WG2 notes that TS 23.682 v13.0 clause 4.2 says:The trust domain (see figure 4.2-2) cover entities that are protected by adequate network domain security. The entities and interfaces within the trust domain may all be within one operator's control, or some may be controlled by a trusted business partner which has a trust relationship with the operator e.g. another operator or a 3rd party. When not under the control of the PLMN operator, it is up to the PLMN operator to ensure that access to the PLMN operator's network from the SCEF is deployed in a manner consistent with security principles of the 3GPP network as outlined by SA WG3 security specifications.","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12091,"Approved","2015-06-05T11:57:42.210","2015-06-05T11:55:31.170","S2-152070","","Rel-13","","","","","","","","S2-151464","SA WG3"]
["S2-152124","Clarification on the overall architecture related with SCEF","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell","Laurent Thiebaut",11066,"CR","","","Summary of change: Clarifies that the SCEF belongs to the HPLMN. Clarifies which southbound interfaces of the SCEF may correspond to raoming. Provides a high level description of the Authorization process for an API","27","6.5","Architecture Enhancements for Service Exposure (AESE)",12441,"Agreed","2015-06-05T11:57:42.227","2015-06-05T11:55:31.277","S2-152109","","Rel-13","23.682","13.1.0","AESE","0119","4","C","SP-150235","","","","",""]
["S2-152125","Enhancing roaming architecture for Service Exposure","Ericsson, AT&T, Nokia Networks","Shabnam Sultana",21207,"CR","","","Summary of change: Introduce a lightweight proxy to aggregate communication with external parties.","28","6.6","Monitoring Enhancements (MONTE)",12671,"Agreed","2015-06-05T11:57:42.397","2015-06-05T11:55:32.260","S2-152110","","Rel-13","23.682","13.1.0","AESE, MONTE","0107","5","B","SP-150236","","","","",""]
["S2-152126","Supporting Class of Users","Nokia Networks","Martin Oettl",17230,"CR","","","Summary of change: Adding a NOTE which clarifies that the pool of identities granted towards a third party owning the WWSF may also be a wildcarded range of identities.","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13281,"Agreed","2015-06-05T11:57:42.490","2015-06-05T11:55:33.947","S2-152113","","Rel-13","23.228","13.2.0","eWebRTCi","1134","3","B","SP-150232","","","","",""]
["S2-152127","Rel-13 Work Item Exception for eWebRTCi","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Rel-13 Work Item Exception for eWebRTCi","30","6.9","Enhancements to WEBRTC ineroperability (eWebRTCi)",13431,"Approved","2015-06-05T11:57:42.583","2015-06-05T11:55:34.850","S2-152057","","Rel-13","","","","","","","","","","","",""]
["S2-152128","FMSS Rel-13 Exception Request","CHINA MOBILE","Tao Sun",54129,"other","","","Rel-13 Exception Request for FMSS","33","6.13","Flexible Mobile Service Steering (FMSS)",15121,"Approved","2015-06-05T11:57:42.617","2015-06-05T11:55:34.850","S2-152053","","Rel-13","23.718","0.3.0","FMSS-SA2TR","","","","","","","","",""]
["S2-152129","Update and Evaluation of extended C-DRX issues 2 and 3","Qualcomm Incorporated","Miguel Griot",43100,"pCR","","","Evaluates the different solutions for extended C-DRX issues 2 and 3","35","6.15","Feasibility study on Extended DRX cycle for Power Consumption Optimization (FS_eDRX)",15601,"Approved","2015-06-05T11:57:42.630","2015-06-05T11:55:35.710","S2-152104","","Rel-13","23.770","0.2.0","FS_eDRX","","","","","","","","",""]
["S2-152130","Rel-13 Work Item Exception for SEW1","Alcatel-Lucent","Laurent Thiebaut",11066,"other","","","Rel-13 Work Item Exception for SEW1. This is the normative WID spinned-off from the phase 1 of FS_SEW. may have to be moved to AI 7.2.","37","6.17","Feasibility study on the Support of Emergency services over WLAN (FS_SEW)",16331,"Approved","2015-06-05T11:57:42.663","2015-06-05T11:55:36.567","S2-152058","","Rel-13","","","","","","","","","","","",""]
["S2-152131","WID for HLCOM normative work","Ericsson","Shabnam Sultana",21207,"WID","","","WID for HLCOM normative work","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16701,"Approved","2015-06-05T11:57:42.693","2015-06-05T11:55:36.583","S2-151874","","Rel-13","","","","","","","","","","","",""]
["S2-152132","WID on Support of Emergency services over WLAN - phase 1","Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, AT&T, Nokia Networks, Sprint, Verizon, Qualcomm Incorporated, Orange, T-Mobile USA, III (Institute for Information Industry), Hewlett-Packard, Broadcom Corporation, TCS, Intel, Rogers Communications, Motorola Mobility, ZTE, Deutsche Telecom, LG Electronics, Huawei, BlackBerry UK Ltd","Laurent Thiebaut",11066,"WID","","","new WID on Support of Emergency services over WLAN - phase 1","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16721,"Approved","2015-06-05T11:57:42.710","2015-06-05T11:55:36.597","S2-151875","","Rel-13","","","","","","","","","","","",""]
["S2-152133","Updated WID for Isolated E-UTRAN Operation for Public Safety","General Dynamics UK Limited","Philip Young",27298,"WID","","","Proposal for Rel-13 stage 2 normative work to follow feature study FS_IOPS_St2","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16741,"Approved","2015-06-05T11:57:42.740","2015-06-05T11:55:36.613","S2-151876","","Rel-13","","","","","","","","","","","",""]
["S2-152134","New Work Item on Extended DRX cycle for Power Consumption Optimization","Qualcomm Incorporated, Verizon, ZTE, Ericsson, Intel, MediaTek Inc., Sierra Wireless, AT&T, Interdigital, Alcatel-Lucent, Sony, LG Electronics","Miguel Griot",43100,"WID","","","Proposes a work item to capture normative work derived from the study FS_eDRX","42","7.1","New and Revised Work Items, Cover sheets for completed work items",16781,"Approved","2015-06-05T11:57:42.770","2015-06-05T11:55:36.630","S2-151878","","Rel-13","","","","","","","","","","","",""]

{"sheet":"CR_Packs_List","index":1,"n_rows":1,"n_cols":11,"rows_kept":1,"cut":false,"hidden":false,"merged":[]}
["CR Pack TDoc #","WG TDoc #","WG TDoc decision","CR Individual TSG decision","Spec #","CR #","CR revision #","CR category","Release","Version","CR title"]

{"sheet":"Parameters","index":2,"n_rows":16,"n_cols":3,"rows_kept":16,"cut":false,"hidden":true,"merged":[]}
["Types of Tdocs","Possible statuses of Tdocs","Categories"]
[]
["agenda","Reserved","A"]
["LS in","Available","B"]
["LS out","Revised","C"]
["pCR","Approved","D"]
["CR","Agreed","E"]
["CR pack","Postponed","F"]
["WID","Noted"]
["WI status report","Rejected"]
["TS or TR","Withdrawn"]
["report","Treated"]
["other","Partially approved"]
[null,"Technically endorsed"]
[null,"Merged"]
[null,"Reissued"]