Guest Editor: Supplement, Standards Comments to the Author: This manuscript has been accepted for publication. Note that as the transition of Communications Standards Supplement to Communications Standards Magazine has been concluded, this manuscript will be queued for publication in the IEEE Communications Standards Magazine. Please prepare your final manuscript in accordance with the Communications Standards Magazine Author Guidelines for submission to the Publications Staff at your earliest opportunity. Reviewer: 2 Comments to the Author There is still no other solution specified or even discussed in 3GPP. So currently it turns out to be a “dual-SIM” solution. There is a proposal on limited backhaul, but that does not change the solution more than it allows visiting UEs getting authenticated towards an external AAA server. As the ”dual-SIM” solution is the one being specified by 3GPP, I have no problems with the revised text of the article, although I still feel that some of the issues it brings up may not be “real world problems”. Reviewer: 1 Comments to the Author The authors addressed my previous comments in a satisfactory manner. --------------------------------------------------------------------------------------------------------------------------------- Round 1 Reviews Guest Editor: Supplement, Standards Comments to the Author: Thank you for your manuscript, it may be accepted for publication. Please note that the reviewers have made some helpful comments to improve the paper quality for the Magazine. Please ensure that these comments are addressed before you submit your revised paper. EDITOR-IN-CHIEF COMMENTS: All references to online sources (website URLs, web-posted papers/reports) are required to show an "Accessed on" date (mm/yyyy). In your revision, please ensure that all references are archival and complete with the publication name, year, volume, issue and page numbers. Reviewer: 1 Comments to the Author This manuscript provides a comprehensive overview on the Isolated E-UTRAN Operation for Public Safety (IOSP). This is a well written and logically organized manuscript on a novel concept in the mobile networks field. In addition, the authors provide the reader with a clear picture of the current status of the IOPS concept and discuss future perspectives to evolve it. However, the following minor issues need to be addressed. Comment 1: Table 1, on page 3, should be replaced by a Figure depicting the overall network architecture of LTE including E-UTRAN and EPC. Table 1 can be an explanatory legend to this Figure. This Figure will allow readers outside the area of LTE to get a clear picture of the high-level network architecture of LTE. Comment 2: In the caption of Figure 2a, it is mentioned that “the already deployed IOPS-capable eNodeBs enter the IOPS mode of operation, connect to a Local EPC, and establish an IOPS network.” However, it is not clear whether each IOPS-capable eNodeB is co-located with a Local EPC or there is only one Local EPC which is deployed as standalone entity and the eNodeBs are connected to it. In other words, it is not clear if Figure 2a covers the case described in Figure 1d, the case described in Figure 1e, or both. A similar clarification is required for Figure 2b, since it is not clear if Figure 2b covers the case described in Figure 1d, the case described in Figure 1e, or both. Comment 3: The evolved NodeB can be abbreviated as eNodeB or eNB. However, only one of these abbreviations should be used in the manuscript. For example on page 4, in lines 2, 41 and 43, the abbreviation “eNB” is used, but on page 4, in lines 5, 10, 12, 39, 40, 41, 42, 51, 52, 53, 55, 56 and 59, the abbreviation “eNodeB” is used. In addition, the abbreviation “eNodeB” is used in Figure 2a, but the abbreviation “eNB” is used in Figure 2b. Comment 4: Figure 4 should be replaced. Comment 5: The following few incoherent sentences need revision: • page 2, lines 15-17: “Their lacks…LTE commercial networks.” • page 2, lines 30-31: “By complying…PMR systems.” • Page 4, lines 14-16: “Subsequent question…next section.” • page 6, lines 38-40: “Since multiple…(Fig 4) [3]:” • page 7, lines 57-58: “A UE…between them.” • page 8, lines 10-11: “All the users-originated traffic…signaling traffic.” • page 8, lines 40-42: “Moreover, the Local EPC…consideration.” • page 9,lines 49-50: “In the case of…dynamic adaptation algorithms.” Comment 6: The following two typographical errors should be corrected: page 1, line 30: responsible of ==> responsible for page 4, lines 40 and 44: deployed on a standalone entity ==> deployed as a standalone entity The word “co-sited” should be replaced by word “co-located” in the whole manuscript. Comment 7: The total number of the words should be decreased since it exceeds the threshold (4500 words) by around 200 words without including the references. Reviewer: 2 Comments to the Author This article is targeting a dual sim solution (mainly to get around the key-sharing problem) but that is not the only solution to IOPS. The big problem with dual sim is that it would require user- or UE application intervention to work and for some customers/usecases that is not desirable. From a dual sim-perspective I do not see any mayor faults with the article. The comments regarding access class and keys are solved with the dual sim solution. The authros should make it clear that the proposed solution is only one option of how to implement IOPS. Comments (in atatcehd PDF): -Why? If the normal PLMN is not available the UE will eventually try to access another PLMN in the area, and it's the EPC of this PLMN that decides if the UE shall be served or not - Is this correct? This requires that the AC for all IOPS users is 11 or 14... If there is a dedicated PS PLMN-ID I assume that the PS users want the freedom to use any AC - I assume that the old APN will be valid as long as the old EPC is available, so it's the unavailability of the normal EPC that triggers the switch rather than the availability of an IOPS EPC - Is this correct? Is it not possible to use the same AKA as the normal core using a "federated HSS"? - I'm not sure these are real-world problems. Local EPCs may only need to support a very limited number of users and the questions listed below, at least 1-5, may thus be superfluous...