1、 ATIS-0700002 UTDOA Lbis Interface: Architecture and Functional Description TECHNICAL REPORT The Alliance for Telecommunication Industry Solutions (ATIS) is a technical planning and standards development organization that is committed to rapidly developing and promoting technical and operations stan
2、dards for the communications and related information technologies industry worldwide using a pragmatic, flexible and open approach. Over 1,100 participants from more than 350 communications companies are active in ATIS 23 industry committees and its Incubator Solutions Program. NOTE - The users atte
3、ntion is called to the possibility that compliance with this standard may require use of an invention covered by patent rights. By publication of this standard, no position is taken with respect to the validity of this claim or any patent rights in connection therewith. The patent holder has, howeve
4、r, filed a statement of willingness to grant license under these rights on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license. Details may be obtained from the publisher. ATIS-0700002, UTDOA Lbis Interface: Architecture and Functional Description Is
5、 an ATIS Standard developed by the UTDOA Ad Hoc Committee under the ATIS Wireless Technologies and Systems Committee (WTSC). Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC 20005 Copyright 2006 by Alliance for Telecommunications Industry So
6、lutions All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. For information contact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. AT
7、IS-0700002 Technical Report on UTDOA LBIS INTERFACE: ARCHITECTURE AND FUNCTIONAL DESCRIPTION Secretariat Alliance for Telecommunications Industry Solutions Approved August, 2004 Abstract This Technical Report describes how the UTDOA position determination system for locating mobile stations may be a
8、pplied to GSM networks in a manner consistent with 3GPP and other relevant standards. UTDOA (uplink time difference of arrival) is one of the location technologies identified in the 3GPP GSM standards. The Lbis interface and Remote PDE Protocol (RPP) enable upgrading earlier proprietary implementati
9、ons of UTDOA to a standards-based solution with minimal impact to the network infrastructure. This document is the first of a three-part set that describe the Lbis interface and RPP in detail. This document describes the functional architecture and the location procedures using call flow diagrams (s
10、tage 2 description). The other two documents will describe, separately, the signaling and OAM protocols (stage 3 description). Informative Annexes to this document cover discussions and concerns raised in the UTDOA technical community during the development of the Lbis interface. ii FOREWORD The All
11、iance for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between carriers, customers, and manufacturers. The Wireless Technologies and Systems Committee (WTSC) formerly T1P1 - develops and recommends standards and technical reports related to wireless an
12、d/or mobile services and systems, including service descriptions and wireless technologies. WTSC develops and recommends positions on related subjects under consideration in other North American, regional and international standards bodies. This document is entitled UTDOA Lbis Interface: Architectur
13、e and Functional Description. This technical report is intended for use in conjunction with standard T1.3GPP.22.071: Location Services (LCS)-Stage 1 and T1.3GPP.23.271: Technical Specification Group Services and System Aspects; Functional stage 2 description of LCS. Footnotes are not officially part
14、 of this document. Future control of this document will reside with Alliance for Telecommunications Industry Solutions. This control of additions to the specification, such as protocol evolution, new applications, and operational requirements, will permit compatibility among U.S. networks. Such addi
15、tions will be incorporated in an orderly manner with due consideration to the ITU-T layered model principles, conventions, and functional boundaries. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, WTSC Secretar
16、iat, 1200 G Street NW, Suite 500, Washington, DC 20005. Committee WTSC chartered the UTDOA Ad Hoc Committee to provide technical assistance in reviewing this report. ATIS-0700002 iii TABLE OF CONTENTS FOREWORD .II INTRODUCTION/EXECUTIVE SUMMARY 1 1 SCOPE, PURPOSE, AND APPLICATION 1 2 NORMATIVE REFER
17、ENCES USED IN THIS TECHNICAL REPORT. 1 3 DEFINITIONS. 2 4 ABBREVIATIONS, ACRONYMS, AND SYMBOLS 2 5 NETWORK ARCHITECTURE, UTDOA ADDITION TO BSS. 4 5.1 LBIS FUNCTIONAL ARCHITECTURE . 4 5.1.1 Lbis Interface . 5 5.1.1.1 RP Link Protocol Details . 6 5.1.2 Lb Interface 7 5.1.3 PDE-LMU interface . 7 5.2 OA
18、 LCS Extension (BSS-LE).1T1.3GPP.48.071 v.6.3.0, Serving Mobile Location Center - Base Station System (SMLC-BSS) interface; Layer 3 specification.1T1.3GPP.43.059 v6.1.0, Functional stage 2 description of Location Services (LCS in GERAN).1T1.3GPP.22.071, Location Services (LCS)-Stage 1.1T1.3GPP.23.27
19、1, Technical Specification Group Services and System Aspects; Functional stage 2 description of LCS.1 3 DEFINITIONS 3.1 Lbis: An interface between a GERAN-defined SMLC and a remote PDE controller such as may be employed in commercially available UTDOA systems. 4 ABBREVIATIONS, ACRONYMS, AND SYMBOLS
20、Table 1provides project-specific terms and acronyms used in this document. Table 1: Abbreviations Layer 3 specification. In order for the BSS to support the operation of a particular PDE, certain specific messages and parameters may need to be passed through the Lb interface. In the case of UTDOA th
21、e Lb interface supports call data including channel, frequency, and AMR status that the PDE needs in order to control the LMUs. Version 6.3.0 of 3GPP TS 48.071 supports the messages and parameters required for UTDOA operation in the Lbis architecture. 5.1.3 PDE-LMU interface This interface is define
22、d within the PDE “black box” model. It is beyond the scope of this document. 5.2 OA the PDE is supported in the PDE vendors OSS. The Lbis architecture does address one specific aspect of OA a single PDE may support location requests originating within the domain of many BSCs but only one PDE serves
23、a given BSC. Depending on the extent of deployment of UTDOA, there may also be BSCs that are not associated with any PDE. Most important, the BSS data can change. A key point is that the organization of the data in the BSS (by cell and by BSC) corresponds to the functional architecture for UTDOA. Fu
24、rthermore, UTDOA needs accurate cell data to be associated with each BSC that it serves. For implementation-specific reasons, a PDE (or other UTDOA subsystem) may require data associated with any arbitrary set of BSCs. (The number of cells supported on a UTDOA controller can be several times larger
25、than the number supported on a typical BSC.) The architecture also assumes support for the transfer of data from the BSS to the UTDOA controller. The benefit of this automatic transfer is to help ensure the accuracy of the data in the UTDOA system (track BSS data changes), while simultaneously reduc
26、ing the cost of manual data maintenance. Figure 4 illustrates the logical partitioning of data within the GSM BSS and the relationships between UTDOA subsystems and the BSC. As shown, in normal mode of operation, a PDE is expected to support transfer of data only from the set of BSCs that it serves
27、and not other BSCs. However, the architecture also allows a subsystem to transfer data from an arbitrary set of BSCs, including those not served by it. This may be useful for, for example, in the case of carrier network sharing of the UTDOA infrastructure. BSC1Cell.Cell.PDE1dataBSC2Cell.Cell.BSCn+1C
28、ell.Cell.BSCxCell.Cell.BSCx+1Cell.Cell.BSCn+mCell.Cell.BSCnCell.Cell.BSCn+2Cell.Cell.BSCx+yCell.Cell.PDE2dataUnassociatedBSCdataOtherU-TDOAsubsystemPDE2PDE1Data-SharinginterfaceU-TDOA networkGSM-BSS.Figure 4: GSM BSS Logical Data and Interested Client Subsystems 8 ATIS-0700002 5.2.1 Data-Sharing Int
29、erface Cell site data used in UTDOA subsystem is available in the SMLC and BSC. A data sharing interface between the GSM BSS and UTDOA subsystems would facilitate data transfer between these subsystems and thereby simplify operations. This is a capability proposed for a RAN Database Synchronization
30、Program (RDSP). See Figure 5 for an illustration of the relationship between the subsystems. The RDSP is proposed for future development. Subsystem Manager SMLC BSC GSM-BSS U-TDOA Subsystem Subsystem Manager PDE LMU Client Server Data-Sharing interface Figure 5: GSM BSS UTDOA Subsystem Interface The
31、 GSM BSS UTDOA subsystem interface does not assume which network entities support the protocols for data sharing within those subsystems. For example, the data source in the BSS could be the BSC, the SMLC, or combinations of those and other network entities. The architecture makes a clear and mainta
32、inable separation between the GSM BSS and UTDOA subsystems. These subsystems could support sharing of the GSM RAN configuration data via a defined protocol-RDSP (RAN Data Synchronization Protocol). In this architecture, the GSM BSS subsystem would be the server providing the configuration data and t
33、he UTDOA subsystem would be the client. Using the Data-Sharing interface, a node within the UTDOA network can establish a data-sharing session with a node within the GSM BSS to collect cell site configuration data. The BSS and UTDOA vendors will define which node in the respective subsystems may be
34、used for a Data-Sharing interface. RDSP or some other protocol could be used by the remote PDE subsystem to share operations data with the RAN or other systems. Similarly, the BSS may allow clients other than the UTDOA subsystems to access and retrieve data using a protocol set up for database admin
35、istration and maintenance. 6 UTDOA POSITIONING PROCEDURE Prerequisites: The MS has initiated a call (for example, emergency call) and is connected over the BSS to the serving MSC/VLR. In the radio interface, the MS is allocated to an SDCCH or a TCH. The MS connection is associated with an SCCP conne
36、ction in the A-interface. The MSC initiates a PerformLocationRequest to determine the position of the MS. 9 ATIS-0700002 BSC PDE LMUSMLCMSBSSMAP-LE PerformLocation RequestRPP Perform Location RequestBSSLAP U-TDOARequestBSSLAP U-TDOAResponseBegin CaptureResponseConfigure.Return TOA Info.BSSMAP-LE Per
37、formLocation ResponseRPP Perform Location ResponseBursts fromMobile StationDeltaTimer145122367891011BSCRetrieve Info.MSCBSSMAP PerformLocation ResponseBSSMAP PerformLocation RequestFigure 6: UTDOA Positioning Message Flow The steps listed in Figure 6 are described as follows: 1. The message “BSSMAP
38、PerformLocationRequest” is sent from the MSC to the BSC over the previously established SCCP connection in the A-interface (SCCPa). The MSC requests positioning of the MS associated with SCCPa. 2. The BSC forwards the message content received in 1, in the message “BSSMAP-LE PerformLocationRequest” t
39、o the SMLC. This is made with an SCCP setup request in the Lb interface (SCCPb). The SCCPa is the reference for the mobile connection in the A-interface. The SCCPb is the identification for the positioning transaction in the Lb interface. The BSC maintains an association between SCCPa and SCCPb duri
40、ng the whole positioning transaction over the Lb interface (2-11 in Figure 6). 3. The SMLC now determines which PDE to task to satisfy the location request (picks which method to use in determining the geographic position of the MS.) The logic used to select the particular positioning method is disc
41、ussed in Clause 6.1 below. The case of interest here is selection of UTDOA. The SMLC requests radio channel information for the MS (SCCPb) from the BSC with the message “BSSLAP UTDOA Request”. An optional “Delta Timer” parameter may be included in this message. The value assigned to the “Delta Timer
42、” is provisioned in the SMLC through the O (not applicable for UTDOA) Supervision timer expired; (not applicable for UTDOA) The following are the expected cause cases of a “BSSLAP Reject” message (from 3GPP TS.48.071): Congestion Channel mode not supported Positioning procedure not supported Failure
43、 for other radio-related events Incorrect serving cell identity; (not applicable for UTDOA) BSSAP-LE segmentation error; (not applicable for UTDOA) Some examples of error situations are as follows: 1. After receiving message 3, the BSC waits for stable conditions for the radio connection to the MS.
44、If handover to another BSC occurs, then the BSC will send Abort as message 4 with cause = (inter-BSS handover). 2. A “PerformLocationRequest” can arrive in the BSC over the Gb interface. In the message 2 to the SMLC, it is not indicated that the connection to the MS is not a CS connection over A-int
45、erface. In this case the BSC will send Reject as message 4 with cause = (channel mode not supported). In this case, the SMLC may invoke another positioning method instead of UTDOA. The UTDOA method expects the BSC to indicate changes in the radio channel to the MS that affect measurement on the upli
46、nk bursts. The relevant RR procedures will be specified in 3GPP TS.43.059 v6.1.0. For the UTDOA method the “BSSLAP Reset” message indicates that changes may be needed in the measurement of uplink bursts. One cause value is needed, but two are allowed within the 3GPP standard. 6.3.1 BSC error cases f
47、or UTDOA method The UTDOA_supervision state in the BSC was introduced in the call flow notes for Figure 6 at the beginning of this clause. UTDOA_supervision state has two values: ON or OFF. The figures below describe procedures for BSSLAP Reset and for BSSLAP Abort/Reject in each of the two supervis
48、ory states. Error cause values for BSSLAP messages defined in the standard 3GPP TS.48.071 are shown for reference in Table 2. ATIS-0700002 Table 2: BSSLAP BSC Error Cause Values Cause Value Description 0000 0000 Congestion 0000 0001 Channel mode not supported 0000 0010 Positioning procedure not supp
49、orted 0000 0011 Failure for other radio-related events 0000 0100 Intra-BSS handover 0000 0101 Supervision timer expired 0000 0110 Inter-BSS handover 0000 0111 Loss of signaling connection to MS 0000 1000 Incorrect serving cell identity 0000 1001 BSSAP-LE segmentation error All unassigned codes are spare. 6.3.1.1 UTDOA_Abort/Reject when UTDOA_supervision is OFF BSC PDESMLCBSSMAP-LE PerformLocation RequestBSSLAP U-TDOARequestBSSLAP Abort orBSSLAP RejectBSSMAP-LE PerformLocation Response14122311BSCMSCBSSMAP PerformLocation
