Title of Invention	A METHOD AND SYSTEM FOR LOCATION SERVICES TESTING FOR USE IN A WIRELESS COMMUNICATION SYSTEM
Abstract	A method and apparatus for conveying the identity of an MS (110) to a standalone Serving Mobile Location Center (SMLC) (130) are described. In one exemplary embodiment, an MS (110) is configured to encode a unique MS identifier (MS ID), such as and International Mobile Subscriber Identity (IMSI), in an extension container, which is an optional information element defined by Radio Resource Location Services (LCS) Protocol (RRLP). The extension container may be included as a component in a Measure Position Response message or a Protocol Error message. The SMLC (130) is configured to decode the extension container, retrieve the MS ID, and store the MS ID in association with a unique the positioning session identifier. Advantageously, the MS (110) may be configured with a test mode parameter. In one embodiment, encoding of the MS ID in the extension container is activated at the test MS (110) only when the test mode parameter is set to an "on" state.

Title of Invention

A METHOD AND SYSTEM FOR LOCATION SERVICES TESTING FOR USE IN A WIRELESS COMMUNICATION SYSTEM

Abstract

A method and apparatus for conveying the identity of an MS (110) to a standalone Serving Mobile Location Center (SMLC) (130) are described. In one exemplary embodiment, an MS (110) is configured to encode a unique MS identifier (MS ID), such as and International Mobile Subscriber Identity (IMSI), in an extension container, which is an optional information element defined by Radio Resource Location Services (LCS) Protocol (RRLP). The extension container may be included as a component in a Measure Position Response message or a Protocol Error message. The SMLC (130) is configured to decode the extension container, retrieve the MS ID, and store the MS ID in association with a unique the positioning session identifier. Advantageously, the MS (110) may be configured with a test mode parameter. In one embodiment, encoding of the MS ID in the extension container is activated at the test MS (110) only when the test mode parameter is set to an "on" state.

Full Text	IDENTIFICATION OF A MOBILE STATION AT A SERVING MOBILE LOCATION CENTER CROSS-REFERENCE TO COPENDING PROVISIONAL APPLICATION This application claims the benefit under 35 U.S.C. § 119(e) of pending U.S. Provisional Application No.60/483,212, filed June 27, 2003, entitled Identification of a Mobile Station at a Serving Mobile Location Center, which is incorporated herein by reference. BACKGROUND L Field [0001] This application relates to the field of location services for mobile devices, and more particularly to a method and apparatus for conveying the identity of a mobile station to a stand-alone Serving Mobile Location Center. 2. Description of Related Art [0002] Location services (abbreviated as LCS, for "LoCation Services") for mobile telephones and wireless digital communication devices (collectively referred to hereinafter as Mobile Stations or MSs) are an increasingly important business area for wireless communication providers. Location services information can be used to provide a variety of location services to mobile station users. For example, public safety authorities can use mobile station location information to pinpoint the precise geographical location of a wireless device. Alternatively, a mobile station user can use location information to locate the nearest automatic teller machine, as well as the fee charged by that ATM. As another example, location information can assist a traveler in obtaining step-by-step directions to a desired destination while en route. [0003] Technologies that permit a large number of system users to share a wireless communication system, such as the Global System for Mobile Communications (GSM) technology, for example, play an important role in meeting the ever-increasing demands of mobile computing, including the demands for location services. As is well known, GSM uses a combination of Time Division Multiple Access and Frequency Division Multiple Access technologies that enable multiple users to communicate simultaneously. GSM systems also frequently employ General Packet Radio Service technology to transmit data and to provide location services. [0004] Standards and functional specifications for MS position ("position" and "location" are used herein as equivalent terms, referring to the geographical coordinates of an MS) determination in wireless communication systems have been established. One exemplary reference relating to GSM and LCS is the "3rd Generation Partnership Project, Technical Specification Group, Services and System Aspects, Location Services (LCS), (Functional description) - Stage 2 (Release 1999)," (3GPP TS 03.71 V8.7.0), September, 2002. The reference is referred to below as 3GPP TS 03.71 V8.7.0. [0005] A second exemplary reference relating to GSM and LCS is the "3rd Generation Partnership Project, Technical Specification Group GSM/EDGE Radio Access Network, Location Services (LCS), Mobile Station (MS) - Serving Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP) (Release 1999)," (3GPP TS 0431 V8.10.0), My, 2002. The reference is referred to hereinafter as 3GPP TS 04.31 V8.10.0. [0006] A third exemplary reference relating to GSM and LCS is the "3rd Generation Partnership Project, Technical Specification Group Core Network, Mobile Application Part (MAP) specification (3G TS 29.002 version 3.h.0 Release 99)," June, 2000. The reference is referred to hereinafter as 3GPP TS 29.002 V3.h.O. [0007] A wireless communications network, such as the Public Land Mobile Communications Network (PIMN) in GSM, can provide assistance data to a MS that enables location measurements and/or improves measurement performance. One exemplary method of MS-assisted positioning employs the Global Positioning System (GPS), and is referred to as "assisted GPS" or AGPS. In accordance with the AGPS techniques, the MS acquires measurements from GPS satellites using assistance data provided by the network. In GSM systems, measurements relating to a given location request are transmitted to a Serving Mobile Location Center (SMLC). The SMLC manages the overall coordination and scheduling of resources required to perform positioning of an MS. [0008] Development and validation of LCS in a wireless communication system requires extensive operational testing. One problem that arises when testing LCS in GSM systems having a stand-alone SMLC, i.e., an SMLC that is not integrated into the Base Station Controller (BSC), is that the identity of a test MS is not communicated to the SMLC in accordance with GSM standard specifications for an LCS positioning session. The identity of an MS is determined using a unique MS identifier (MS ID) such as an International Mobile Subscriber Identity (MSI) number. The MS ID is generally available in a Subscriber Identity Module ((SIM), or other equivalent component within the MS. The MS ID of an MS that receives services is provided to the BSC. However, during a positioning session, the BSC conveys only a logical reference datum to the SMLC to distinguish one positioning session from another. Although this is an effective method for ordinary operation, it makes testing very difficult because an information recovery process must be accomplished in order to associate a particular session to a specific MS. [0009] Possible methods of addressing the MS identity testing problem noted above may include integrating the SMLC in the BSC, or modifying the BSC such that the MS identity information is passed to the SMLC in a non-standard manner. However, these methods are undesirable because such changes to the BSC are cumbersome and difficult to accomplish. [0010] Therefore, an effective method and apparatus for conveying the identity of an MS to a stand-alone SMLC during an LCS positioning session are needed to facilitate operational testing. SUMMARY [0011] A method and apparatus for providing the geographical location of a wireless mobile station, and more particularly to a method and apparatus for conveying the identity of an MS to a stand-alone Serving Mobile Location Center (SMLC) has, in one exemplary embodiment, an MS configured to encode its unique MS identifier (MS ID), such as an International Mobile Subscriber Identity (IMSI), in an extension container, which is an optional information element defined by Radio Resource Location Services (LCS) Protocol (RRLP). The extension container may be included as a component in a location services message such as a Measure Position Response message or a Protocol Error message. The SMLC is configured to decode the extension container, retrieve the MS ID, and store the MS ID in association wife a unique positioning session identifier. [0012] Advantageously, the MS may be configured with a test mode parameter. The test mode parameter may be set to the values "test mode on" (abbreviated "ON") and "test mode off* (abbreviated "OFF"), where the default value is "OFF." In the MS, the configuration of the test mode parameter may be controlled via a proprietary command using a serial link into the phone, or via the MS user interface. In one embodiment, encoding of the MS ID in the extension container is activated at the test MS only when the test mode parameter is set to "ON." BRIEF DESCRIPTION OF THE DRAWINGS [0013] FIGURE 1 is a functional block diagram of an exemplary wireless communication system used to provide wireless communications including location services. [0014] FIGURE 2 is a functional block diagram of another exemplary wireless communication system used to provide wireless communications including location services, showing additional system components. [0015] FIGURE 3 is a functional block diagram illustrating the flow of messages between a test mobile station and a Serving Mobile Location Center. [0016] FIGURE 4 is a flowchart diagram illustrating steps of an exemplary method. DETAILED DESCRIPTION [0017] FIGURE 1 illustrates a simplified general wireless communication system 100 that may be adapted for testing location services. As shown in FIGURE 1, a Mobile Station (MS) 110 communicates with one or more Base Transceiver Stations (BTSs) 122,124 via wireless links 152,154. Each BTS provides coverage (or service) to a geographical region commonly referred to as a "cell". Although two BTSs are illustrated by way of example, depending on the positioning mechanisms employed, location services may be provided to the MS 110 using only one BTS, or using three or more BTSs. As described in the incorporated 3GPP TS 03.71 V8.7.0 reference, positioning mechanisms may include Uplink Time of Arrival (TOA), Enhanced Observed Time Difference (E-OTD), and AGPS. Both TOA and E-OTD require an exchange of signals between the MS and a plurality of BTSs. [0018] In accordance with the present teachings, the MS 110 may include, without limitation: a wireless telephone, a personal digital assistant with wireless communication capabilities, a laptop having wireless communication capabilities, and any other mobile digital device for personal communication via wireless connection. [0019] The BTSs 122,124 are operatively coupled for data communication to a Base Station Controller (BSC) 126. The BTSs 122,124 and the BSC 126 are part of a Base Station System 120. As shown in FIGURE 1, the BSC 126 is coupled to a Serving Mobile Location Center (SMLC) 130. An SMLC controls location services by managing the resources required to perform positioning of an MS. In alternative configurations, the SMLC may be operatively coupled through other elements (not shown) in the wireless communication system. [0020] The MS 110 may receive signals, such as GPS signals, from one or more satellites 172,174 via communication links 156,158. Although two satellites are illustrated by way of example, only one satellite, or more usually, a plurality of satellites, may be employed when providing location services to a mobile station in a wireless communication system. Satellite data may also be received by other receivers (not shown) in the communication service provider network 140. Persons skilled in the communication arts will understand that GPS location systems for wireless systems generally include elements such as stationary GPS receivers and/or Wide Area Reference Networks for receiving satellite signals and providing reference data to SMLCs. The BSC 126 is coupled to the communication service provider network 140 to receive and transmit data such as audio/video/text communication and programming data, position requests, etc. One example of a communication service provider network is a Public Land Mobile Communication System Network (PLMN) operating under GSM. [0021] FIGURE 2 shows another exemplary communication system 200 capable of providing location services, illustrated in functional block form. For simplicity, only one GPS satellite 272, and its associated broadcast signal link 252, is illustrated, f 0022J As shown in FIGURE 2, the MS 210 includes a central processing unit (CPU) 212, a memory 214, a User Interface 213, a Subscriber Identity Module (SIM) 215, and a transceiver 216. The term "CPU", as used throughout this description, is intended to encompass any processing device, alone or in combination with other devices (such as a memory), capable of controlling operation of a device (such as an SMLC 230 or the MS 210, or a portion thereof) in which it is included. For example, a CPU can include microprocessors, embedded controllers, application specific integrated circuits (ASICs), digital signal processors (DSPs), state machines, dedicated discrete hardware, and the like. The system, apparatus, and method described herein are not limited to the specific hardware component described or by any specific hardware component selected to implement the CPU 212. [0023 J The transceiver 216 enables transmission and reception of data, such as audio/video/text communication and programming data, between the MS 210 and a remote location, such as the BTSs 224 and 226, or GPS satellites such as the satellite 272. An antenna 218 is electrically coupled to the transceiver 216. The basic operation of the MS 210 for voice and data communication is well-known in the art and is not described in detail herein. [0024J As shown in FIGURE 2, the system 200 includes a SMLC 230 having a memory 234, and a CPU 232. The CPU 232 controls the operation of the SMLC 230 according to programmed instructions and data stored in the memory 234. The memories 214 and 234 may include read-only memory (ROM) components, random-access memories (RAM), and non-volatile RAM components. The memory 234 stores and provides instructions and data for the CPU 232. The memory 214 stores and provides instructions and data for the CPU 212. The components of the SMLC 230 are linked together by an internal bus system 236. The components of the MS 210 are linked together by an internal bus system 219. [0025] As described in more detail below, the SIM 215 includes a unique MS identifier (MS ID), such as an International Mobile Subscriber Identity (EMSI), Mobile Subscriber Integrated Services Directory Number (MSISDN), or other MS ID. The MSI and MSISDN are unique identifiers for an MS, and either may be used. The MS ID (typically an IMSI, although the MSISDN or other MS IDs may be employed) may be retrieved by the CPU 212, encoded according to programmed instructions and data stored in the memory 214, incorporated into an RRLP Measure Position Response message or a Protocol Error message, and conveyed to the SMLC 230 via the communication links and system components illustrated in FIGURE 2. [0026] The User Interface 213 may be used to control the setting of a test mode parameter, as described below. In one exemplary embodiment, the User Interface may include a graphical user interface (GUI), and input devices such as a touch screen, pointing device or keypad. In another exemplary embodiment, the test mode parameter may be controlled using a proprietary command received through a connection (e.g., a serial connection, not shown) to a local device (not shown), such as a laptop computer or personal digital assistant, wherein the local device is operatively connected to the CPU 219. f0027] As shown in FIGURE 2, the communication system 200 includes a BSS 220, which, in turn, includes a BSC 222 and a plurality of BTSs such as the BTSs 224,226. The BTSs permit the transmission and reception of data (such as audio/video/text and programming data) between the BSC 222 and remote locations, such as the MS 210, or GPS satellites, such as satellite 272. Antennas 228 and 229 are electrically coupled to the BTSs 224 and 226, respectively, in known manner. The MS 210 communicates with the BTSs via wireless links such as the wireless link 272. Additional radio links (not shown) may be used to transmit signals between the MS 210 and the BTS 224 or other BTSs (not shown). The basic operation of the BSC 222 and BTSs 224,226 is well-known in the art and therefore is not described in more detail herein. The BSC 222 is connected to the Communication Service Provider Network 240. The BSC 222 receives and transmits data, such as audio/video/text communication and programming data, position requests, or position data from the Communication Service Provider Network 240. [0028] The BSC 220 is also coupled to the SMLC 230 in order to transmit and receive data relating to LCS. Examples of such data are described in detail below. [0029] RRLP LCS Messages Exchanged between the MS and the SMLC [0030] Figure 3 illustrates the flow of RRLP messages that may be exchanged between a test MS 310 and an SMLC 330 during a position request procedure. This procedure is described in greater detail in the reference 3GPP TS 04.31 V8.10.0. [0031] The RRLP Assistance Data message 342, RRLP Protocol Error message 346, and RRLP Assistance Data Acknowledgement message 348 enable the SMLC to transmit assistance data to the MS relating to position measurement and/or MS location calculation when RRLP downlink pseudo-segmentation is used (according to well known art, as described in 3 GPP TS 04.31 V8.10.0). If pseudo-segmentation is not used, the position request procedure skips the messages 342, 346 and 348. The RRLP Assistance Data message 342, the RRLP Protocol Error message 346, and the RRLP Assistance Data Acknowledgement message 348 may also enable the SMLC to transmit assistance data requested by the MS. In this case messages 352, 354 and 356 are skipped. [0032] Using the RRLP Assistance Data message 342, or the RRLP Measure Position Request message 352, the SMLC transmits the Assistance Data component to the MS. This component includes assistance data for location measurement and/or location calculation. [0033] The MS transmits an RRLP message containing the Protocol Error component to the SMLC using the RRLP Protocol Error message 346. This message is sent only if there is a problem that prevents the MS from receiving a complete and understandable Assistance Data component (the contingent aspect of the message is signified in the FIGURE 3 by using a dashed line). The Protocol Error message 346 includes an optional information element referred to as an extension container. As described below in more detail, the extension container of the Protocol Error message 346 may be adapted to convey the MS ID (e.g., MSI or MSISDN) of the MS to the SMLC. This message is conveyed when there is a protocol error. Consequently, as described below, subsequent messages may be utilized for MS identity conveyance. [0034J When the MS has received the complete Assistance Data component, it transmits the RRLP, Assistance Data Acknowledgement message 348, to the SMLC. [0035] The SMLC transmits the Measure Position Request component to the MS using the RRLP Measure Position Request message 352. This component includes Quality of Service (QoS), other instructions, and possible assistance data. [0036] The MS transmits an RRLP message containing the Protocol Error component to the SMLC using the RRLP Protocol Error message 354. This message is transmitted only if there is a problem that prevents the test MS from receiving a complete and understandable Measure Position Request component. The Protocol Error message 354 also includes an optional extension container that may be adapted to convey the MS ID (e.g., MSI or MSISDN) of the MS to the SMLC. However, this message is conveyed only if an error is encountered. Consequently, the subsequent message described below maybe utilized to convey,MS identity. [0037] The MS attempts to report the requested location measurements using the RRLP Measure Position Response message 356. Examples of location measurements may include a position estimate, AGPS measurements, or a measurement error. When the MS has location measurements, position estimate, or an error indication (measurements/location estimation not possible), it transmits the results in the Measure Position Response component to the SMLC. [0038] The RRLP Measure Position Response message 356 also includes an optional extension container that may be adapted to convey the MS ID (e.g., IMSI or MSISDN) of the MS to the SMLC. If the position determination process has not been previously aborted due to an error, the extension container of this message may be implemented in order to convey the MS ID to the SMLC. If the process is aborted prior to this message, then one of the Protocol Error messages 346 or 354 may used instead. Extension Container Specification [0039] The RRLP extension container is exported from the Mobile Application Part (MAP) Extension Data Types (described in detail in the incorporated 3GPP TS 29.002 V3.h.O reference). As a result, its specification complies with the MAP Abstract Syntax Notation One (ASN.l) description rules. For the actual field encoding/decoding, the Packed Encoding Rules (PER) PER apply (e.g., bitmap for optional parameters, extension indicator when the ellipsis notation is used, etc). As described below, the MAP compliant encoding involves object identifiers, which were either previously registered or are yet to be registered. [0040] An exemplary ASN-1 encoding of the extension container is given in the pseudo-code below. MAP-EXTENSION ::= CLASS { &ExtensionType OPTIONAL, &extensionId OBJECT IDENTIFIER } ExtensionContainer ::= SEQUENCE { privateExtensionList [0]PrivateExtensionList OPTIONAL, pcs-Extensions [l]PCS-Extensions OPTIONAL, ...} PrivateExtensionList ::= SEQUENCE SIZE (L.maxNumOfPrivateExtensions) OF PrivateExtension maxNumOfPrivateExtensions INTEGER ::= 10 PrivateExtension ::= SEQUENCE { extld MAP-EXTENSION.&extensionld ({ExtensionSet}), extType MAP-EXTENSION.&ExtensionType ({ExtensionSet} {@extld}) OPTIONAL} [0041] In accordance with one embodiment, the MS identification may be encoded in the extType variable. The optional PCS-Extensions are not included in this exemplary embodiment. The OI should not be confused with the IMSI or other MS ED which may be used to identify the test MS. The content of the OI, or the OI "value", is preceded by a length indicator that provides the number of octets of the OI value. [0042] As described in the incorporated references, the ASN-1 OI enables unambiguous identification of an entity that is registered in a worldwide tree. The properties of OIs are well known to persons skilled in the art of wireless communications, and therefore are not described in more detail herein. OIs may be registered through an appropriate organization or registration authority. An example of an existing OI registration, similar to that which would be suitable for an exemplary embodiment, is the one assigned for the ASN-1 BASIC-PER, UNALIGNED variant: {joint-iso-itu-t asnl (1) packed-encoding (3) basic ( O ) unaligned (1)} "Packed encoding of a single ASN.l type (basic unaligned)." A suitable OI may be represented by the known PER hexadecimal format and used for the "extld" entry of the exemplary ASN-1 encoding of the extension container shown above. For this example, the OI is represented by the decimal numbers "1,3, 0,1", which may be encoded by the PER hexadecimal sequence 0x03, 0x2b, 00, 01 (0x03 is the variable length value of 3 octets; 0x2b represents the value 43 = 40*1 + 3). [0043] In one embodiment, the "ectype" variable is the component containing the private extension data that may be used to convey the IMSI or other MS ID for the test MS. It is an ASN-1 open type, therefore it has a length determinant followed by a field list. For the current example, the length of the private extension may be selected not to exceed 128 octets. The length determinant may therefore be encoded in one octet, or in 8 bits, hi one embodiment, the field list for the extType variable may have the following format: FieldList ::= SEQUENCE { testExtRevision TestExtensionRevision, imsi IMSI, • • • } [0044] In the example above, the following notes apply: The ellipsis notation "..." indicates that extensions can be added. If the test MS in some exceptional case cannot provide its IMSI, the IMSI field may be filled with zeros. The TestExtension Revision is an integer variable having a value between 0 and 63, inclusive, and may be represented by a 6-bit hexadecimal number. The IMSI variable is an octet string with a fixed size of 8 octets. [0045] TABLE 1 is an exemplary extension container encoding in accordance with the teachings above: Test MS Identification by the SMLC and Exemplary Operation {0046] In one exemplary embodiment, a test MS is configured to encode its associated MS ID (e.g., MSI or MSISDN) in an extension container of the Measure Position Response message 356, or in an extension container of the Protocol Error messages 346 and 354 (FIGURE 3). As described above, the Measure Position Response message is transmitted to an SMLC to report a position determination, AGPS measurements, or a measurement error. The Protocol Error messages are transmitted by the test MS to an SMLC to report a protocol error. The SMLC is configured to decode the extension container, retrieve the MS ID, and store the MS ID in association with a unique positioning session identifier that may belong to a plurality of position session identifiers maintained by the SMLC. [0047] When attempting to decode a private extension, the SMLC may first attempt to decode the 01. If the received OI is not recognized, the SMLC may attempt to skip the OI and decode the length of the open type variable in order to skip the entire private extension container. If the extension container prevents proper decoding of the RRLP message, the SMLC may transmit a RRLP Protocol Error message to the MS and terminate the position determination session with the BSC. [0048] Whenever the SMLC detects that the length determinant of the OI, or of the ExtType, is encoded with a value indicating that the length is greater than 16K, the SMLC transmits a protocol Error message to the MS. The SMLC terminates the position determination session with the BSC. [0049J Advantageously, the MS may be configured with a test mode parameter. The test mode parameter may be set with the values "test mode on" (abbreviated "ON") and "test mode off' (abbreviated "OFF"), where the default value is "OFF." In the MS, the configuration is done through a proprietary command using a serial link into the phone or via the MS user interface (UT). Encoding of the MS ID in a message extension container is activated at the test MS only when the test mode parameter is set to "ON." In one embodiment, encoding of the MS ED in the extension container is activated at the test MS only when the test mode parameter is set to "ON." [0050J FIGURE 4 is a flowchart diagram illustrating steps in an exemplary method. At a STEP 402, an MS receives a message from an SMLC. Exemplary messages may include an RRLP Assistance Data message or an RRLP Measure Position Request Message. The method proceeds to a STEP 404. [0051] Optionally, the MS may be equipped with a test mode parameter. If the MS is programmed to encode the MS ID and does not have a test mode parameter, then the STEP 404 maybe skipped and the method proceeds directly to a STEP 406. If the test mode parameter is included in the MS, and it is set to ON, the concept also proceeds to the STEP 406. If the MS is not programmed to send an MS ID, or if the test mode parameter is set to OFF, the method proceeds to a STEP 408. [0052J At the STEP 406, the MS encodes its associated MS ID in an extension container of a suitable response message, such as the Measure Position Response message 356 (FIGURE 3), the Protocol Error messages 346 and 354. Suitable messages may include any messages having an extension container. Other messages that may be sent that do not have an extension container, such as the Assistance Data Acknowledgement message, are not employed for encoding the MS ID, and are not referred to by the steps shown in FIGURE 4. The method proceeds to a STEP 408. [0053] At the STEP 408 the MS transmits the suitable response message to the SMLC, and proceeds to a STEP 410. [00541 At the STEP 410 the SMLC processes the suitable response message and proceeds to a STEP 412. [0055] At the STEP 412, if the SMLC is appropriately configured to retrieve the MS ID from the extension container, the method proceeds to a STEP 414. If the SMLC fails to retrieve the MS ID, the method proceeds to a STEP 416. If no MS ID was sent (e.g., the test mode was set to OFF), the method also proceeds to the STEP 416. [0056] At the STEP 414, the SMLC stores the MS ID in association with a unique positioning session identifier for reference by test engineers as needed, and then continues normal processing functions. [0057] At the STEP 416, the SMLC may respond by transmitting an RRLP Protocol Error message to the MS, and terminating the position determination session with the BSC, before continuing with normal processing functions. Alternatively, if the MS did not send an MS ID (e.g., the test mode was OFF) the SMLC will also continue with normal processing functions at the STEP 416. As another possibility, the SMLC may transmit an RRLP Protocol Error message to the MS without terminating the position determination session with the BSC, before continuing with normal processing functions. These possible responses by the SMLC are discussed further below. [0058] Several advantageous novel aspects exist. For example, the implementation of a private extension only impacts operation of the MS and the SMLC. It does not impact the operation of other network elements such as the BSS, the BSC or the Mobile Switching Center (not shown in the FIGURES). The MS identification method and apparatus does not impact other elements because RRLP messages are passed transparently by the BSC, and only the size of the RRLP message is a factor for the BSC processing of the message. [0059] Another advantageous aspect relates to the interoperability between a test MS and a "naive" SMLC (i.e., an SMLC that is not configured for operation in a test mode according to the teachings herein). If an SMLC is unable to decode the extension container (e.g., as could occur with a roaming situation, although roaming would be an atypical circumstance for operation of a test MS), several possibilities may occur: 1) when the naive SMLC detects the presence of the optional extension container, it may choose not to attempt to decode the message and may transmit a Protocol Error message in response; 2) when the extension container is at the end the message, the naive SMLC may attempt to decode the message, but stop the decoding upon reaching the extension container, thereby processing the part of the message decoded before reaching the extension container; 3) the naive SMLC maybe capable of decoding extension containers, but decides to discard private extensions for which it does not recognize the 01. For the cases 2) and 3) above, positioning operability is maintained. However, for case 1) above the test MS will not have positioning operability unless the test mode parameter is implemented and set to "OFF". [0060] Yet another advantageous feature relates to the size of the RRLP Measure Position Response message. The addition of a private extension increases the size of the RRLP payload, which may be an issue in terms of segmentation, especially for the RRLP Measure Position Response message. However, if the message size remains under 252 octets, no uplink segmentation is required. The exemplary embodiment described above limits the increase in the size of the RRLP message to 128 octets (120 octets is the typical number for reporting one set of GPS measurements associated with 16 satellites) or less, reducing the possibility that the complete RRLP message will exceed 252 octets. [0061] Those of ordinary skill in the communications and computer arts shall recognize that computer readable medium that tangibly embodies the method steps of any of the embodiments described herein may be used in accordance with the present teachings. Such a medium may include, without limitation, RAM, ROM, EPROM, EEPROM, floppy disk, hard disk, CD-ROM, etc. The disclosure also includes the method steps of any of the foregoing embodiments synthesized as digital logic in an integrated circuit, such as a Field Programmable Gate Array, or Programmable Logic Array, or other integrated circuits that can be fabricated or modified to embody computer program instructions. [0062] The Mobile Stations 110 and 210, in accordance with the present teachings may include, without limitation: a wireless telephone, a personal digital assistant with wireless communication capabilities, a laptop having wireless communication capabilities, and any other mobile digital device for personal communication via wireless connection. [0063] A number of embodiments have been described. Nevertheless, it will be understood that the methods described herein may be executed in software or hardware, or a combination of hardware and software embodiments. As another example, it should be understood that the functions described as being part of one module may, in general, be performed equivalently in another module. As yet another example, steps or acts shown or described in a particular sequence may generally be performed in a different order, except for those embodiments described in a claim that include a specified order for the steps. CLAIMS 1. A location services testing method for use in a wireless communication system, comprising the steps of: a) receiving a first location services message at a Mobile Station (MS); b) encoding a unique MS identifier in an extension container of a second location services message; c) transmitting the second location services message to a Serving Mobile Location Center (SMLC), responsive to the first location services message, wherein the SMLC maintains a plurality of positioning session identifiers; d) decoding the extension container thereby retrieving the unique MS identifier; and e) storing the unique MS identifier corresponding to and associated with a unique positioning session identifier belonging to the plurality of positioning session identifiers. 2. The location services testing method of Claim 1, wherein the first location services message is a Radio Resource Location Services (LCS) Protocol (RRLP) Assistance Data message. 3. The location services testing method of Claim 1, wherein the first location services message is an RRLP Measure Position Request message. 4. The location services testing method of Claim 1, wherein the unique MS identifier is an International Mobile Subscriber Identity. 5. The location services testing method of Claim 1, wherein the unique MS identifier is a Mobile Subscriber Integrated Services Directory Number. 6. The location services testing method of Claim 1, wherein the step of encoding the unique MS identifier further includes the step of setting a test mode parameter that controls the encoding of the unique MS identifier. 7. The location services testing method of Claim 1, wherein the second location services message is an RRLP Protocol Error message. 8. The location services testing method of Claim 1, wherein the second location services message is an RRLP Measure Position Response message. 9. A system for testing location services in a wireless communication system, comprising: a) a mobile station (MS) capable of performing location services functions, wherein the MS includes: i) a transceiver, adapted to receive a first location services message, and adapted to transmit a second location services message; and ii) an MS CPU, operatively coupled to the transceiver, wherein the MS CPU receives the first location services message, and wherein the MS CPU encodes an MS identifier uniquely identifying the MS, and wherein the MS CPU inserts the unique MS identifier in an extension container of the second location services message; b) a Base Station System (BSS), wherein the BSS includes a Base Transceiver Station (BTS) adapted to transmit the first location services message to the MS and adapted to receive the second location services message from the MS; and c) a Serving Mobile Location Center (SMLC) that controls the location services for the wireless communication system, wherein the SMLC maintains a plurality of positioning session identifiers, and wherein the SMLC includes: i) an SMLC CPU, operatively coupled to the BSS, wherein the SMLC CPU outputs the first location services message and transmits the first location services message to the BSS, and wherein the SMLC CPU receives the second location services message from the BSS and decodes the extension container of the second location services message thereby retrieving the unique MS identifier; and ii) a memory, coupled to the SMLC CPU, wherein the memory stores the unique MS identifier corresponding to and associated with a unique positioning session identifier among the plurality of positioning session identifiers, 10. The system for testing location services of claim 9, wherein the MS CPU includes a test mode parameter, and wherein the MS CPU encodes the MS identifier and inserts the unique MS identifier in an extension container responsive to a setting of the test mode parameter. 11. The system for testing location services of claim 10, wherein the MS includes a User Interface, and wherein the User Interface is coupled to the MS CPU to control the setting of the test mode parameter. 12. The system for testing location services of claim 9, wherein the second location services message is a Radio Resource Location Services (LCS) Protocol (RRLP) Measure Position Response message. 13. The system for testing location services of claim 9, wherein the second location services message is an RRLP Protocol Error message. 14. The system for testing location services of claim 9, wherein the first location services message is an RRLP Assistance Data message. 15. The system for testing location services of claim 9, wherein the first location services message is an RRLP Measure Position Request message. 16. The system for testing location services of claim 9, wherein the MS includes a Subscriber Identity Module ((SIM) that stores the unique MS identifier. 17. The system for testing location services of claim 9, wherein the unique MS identifier is an International Mobile Subscriber Identity. 18. The system for testing location services of claim 9, wherein the unique MS identifier is a Mobile Subscriber Integrated Services Directory Number. 19. A system for testing location services in a wireless communication system, comprising: a) means for receiving a first location services message; b) means for encoding a unique MS identifier in an extension container of a second location services message; c) means for transmitting the second location services message to a Serving Mobile Location Center (SMLC), responsive to the first location services message, wherein the SMLC maintains a plurality of positioning session identifiers; d) means for decoding the extension container of the second location services message thereby retrieving the unique MS identifier; and e) means for storing the unique MS identifier corresponding to and associated with a unique positioning session identifier among the plurahty of positioning session identifiers. 20. A computer program executable on a general purpose computing device, wherein the program is capable of performing location services testing in a wireless communication system comprising a plurality of mobile stations and a plurality of base stations, comprising: a) a first set of instructions for receiving a first location services message at a Mobile Station (MS); b) a second set of instructions for encoding a unique MS identifier into an extension container of a second location services message; c) a third set of instructions for transmitting the second location services message to a Serving Mobile Location Center (SMLC), responsive to the first location services message, wherein the SMLC maintains a plurality of positioning session identifiers; d) a fourth set of instructions for decoding the extension container thereby retrieving the unique MS identifier; and e) a fifth set of instructions for storing the unique MS identifier corresponding to and associated with a unique positioning session identifier belonging to the plurality of positioning session identifiers.

Full Text

IDENTIFICATION OF A MOBILE STATION AT A SERVING MOBILE LOCATION
CENTER
CROSS-REFERENCE TO COPENDING PROVISIONAL APPLICATION
This application claims the benefit under 35 U.S.C. § 119(e) of pending U.S. Provisional Application No.60/483,212, filed June 27, 2003, entitled Identification of a Mobile Station at a Serving Mobile Location Center, which is incorporated herein by reference.
BACKGROUND
L Field
[0001] This application relates to the field of location services for mobile devices, and more particularly to a method and apparatus for conveying the identity of a mobile station to a stand-alone Serving Mobile Location Center.
2. Description of Related Art
[0002] Location services (abbreviated as LCS, for "LoCation Services") for mobile telephones and wireless digital communication devices (collectively referred to hereinafter as Mobile Stations or MSs) are an increasingly important business area for wireless communication providers. Location services information can be used to provide a variety of location services to mobile station users. For example, public safety authorities can use mobile station location information to pinpoint the precise geographical location of a wireless device. Alternatively, a mobile station user can use location information to locate the nearest automatic teller machine, as well as the fee charged by that ATM. As another example, location information can assist a traveler in obtaining step-by-step directions to a desired destination while en route. [0003] Technologies that permit a large number of system users to share a wireless communication system, such as the Global System for Mobile Communications (GSM) technology, for example, play an important role in meeting the ever-increasing demands of mobile computing, including the demands for location services. As is well known, GSM uses a combination of Time Division Multiple Access and Frequency Division Multiple Access technologies that enable multiple users to communicate simultaneously. GSM systems also frequently employ General Packet Radio Service technology to transmit data and to provide location services.

[0004] Standards and functional specifications for MS position ("position" and "location" are used herein as equivalent terms, referring to the geographical coordinates of an MS) determination in wireless communication systems have been established. One exemplary reference relating to GSM and LCS is the "3rd Generation Partnership Project, Technical Specification Group, Services and System Aspects, Location Services (LCS), (Functional description) - Stage 2 (Release 1999)," (3GPP TS 03.71 V8.7.0), September, 2002. The reference is referred to below as 3GPP TS 03.71 V8.7.0. [0005] A second exemplary reference relating to GSM and LCS is the "3rd Generation Partnership Project, Technical Specification Group GSM/EDGE Radio Access Network, Location Services (LCS), Mobile Station (MS) - Serving Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP) (Release 1999)," (3GPP TS 0431 V8.10.0), My, 2002. The reference is referred to hereinafter as 3GPP TS 04.31 V8.10.0. [0006] A third exemplary reference relating to GSM and LCS is the "3rd Generation Partnership Project, Technical Specification Group Core Network, Mobile Application Part (MAP) specification (3G TS 29.002 version 3.h.0 Release 99)," June, 2000. The reference is referred to hereinafter as 3GPP TS 29.002 V3.h.O. [0007] A wireless communications network, such as the Public Land Mobile Communications Network (PIMN) in GSM, can provide assistance data to a MS that enables location measurements and/or improves measurement performance. One exemplary method of MS-assisted positioning employs the Global Positioning System (GPS), and is referred to as "assisted GPS" or AGPS. In accordance with the AGPS techniques, the MS acquires measurements from GPS satellites using assistance data provided by the network. In GSM systems, measurements relating to a given location request are transmitted to a Serving Mobile Location Center (SMLC). The SMLC manages the overall coordination and scheduling of resources required to perform positioning of an MS.
[0008] Development and validation of LCS in a wireless communication system requires extensive operational testing. One problem that arises when testing LCS in GSM systems having a stand-alone SMLC, i.e., an SMLC that is not integrated into the Base Station Controller (BSC), is that the identity of a test MS is not communicated to the SMLC in accordance with GSM standard specifications for an LCS positioning session. The identity of an MS is determined using a unique MS identifier (MS ID) such

as an International Mobile Subscriber Identity (MSI) number. The MS ID is generally available in a Subscriber Identity Module ((SIM), or other equivalent component within the MS. The MS ID of an MS that receives services is provided to the BSC. However, during a positioning session, the BSC conveys only a logical reference datum to the SMLC to distinguish one positioning session from another. Although this is an effective method for ordinary operation, it makes testing very difficult because an information recovery process must be accomplished in order to associate a particular session to a specific MS.
[0009] Possible methods of addressing the MS identity testing problem noted above may include integrating the SMLC in the BSC, or modifying the BSC such that the MS identity information is passed to the SMLC in a non-standard manner. However, these methods are undesirable because such changes to the BSC are cumbersome and difficult to accomplish.
[0010] Therefore, an effective method and apparatus for conveying the identity of an MS to a stand-alone SMLC during an LCS positioning session are needed to facilitate operational testing. SUMMARY
[0011] A method and apparatus for providing the geographical location of a wireless mobile station, and more particularly to a method and apparatus for conveying the identity of an MS to a stand-alone Serving Mobile Location Center (SMLC) has, in one exemplary embodiment, an MS configured to encode its unique MS identifier (MS ID), such as an International Mobile Subscriber Identity (IMSI), in an extension container, which is an optional information element defined by Radio Resource Location Services (LCS) Protocol (RRLP). The extension container may be included as a component in a location services message such as a Measure Position Response message or a Protocol Error message. The SMLC is configured to decode the extension container, retrieve the MS ID, and store the MS ID in association wife a unique positioning session identifier. [0012] Advantageously, the MS may be configured with a test mode parameter. The test mode parameter may be set to the values "test mode on" (abbreviated "ON") and "test mode off* (abbreviated "OFF"), where the default value is "OFF." In the MS, the configuration of the test mode parameter may be controlled via a proprietary command using a serial link into the phone, or via the MS user interface. In one embodiment,

encoding of the MS ID in the extension container is activated at the test MS only when
the test mode parameter is set to "ON."
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] FIGURE 1 is a functional block diagram of an exemplary wireless
communication system used to provide wireless communications including location
services.
[0014] FIGURE 2 is a functional block diagram of another exemplary wireless
communication system used to provide wireless communications including location
services, showing additional system components.
[0015] FIGURE 3 is a functional block diagram illustrating the flow of messages
between a test mobile station and a Serving Mobile Location Center.
[0016] FIGURE 4 is a flowchart diagram illustrating steps of an exemplary method.
DETAILED DESCRIPTION
[0017] FIGURE 1 illustrates a simplified general wireless communication system 100
that may be adapted for testing location services. As shown in FIGURE 1, a Mobile
Station (MS) 110 communicates with one or more Base Transceiver Stations (BTSs)
122,124 via wireless links 152,154. Each BTS provides coverage (or service) to a
geographical region commonly referred to as a "cell". Although two BTSs are illustrated
by way of example, depending on the positioning mechanisms employed, location
services may be provided to the MS 110 using only one BTS, or using three or more
BTSs. As described in the incorporated 3GPP TS 03.71 V8.7.0 reference, positioning
mechanisms may include Uplink Time of Arrival (TOA), Enhanced Observed Time
Difference (E-OTD), and AGPS. Both TOA and E-OTD require an exchange of signals
between the MS and a plurality of BTSs.
[0018] In accordance with the present teachings, the MS 110 may include, without
limitation: a wireless telephone, a personal digital assistant with wireless
communication capabilities, a laptop having wireless communication capabilities, and
any other mobile digital device for personal communication via wireless connection.
[0019] The BTSs 122,124 are operatively coupled for data communication to a Base
Station Controller (BSC) 126. The BTSs 122,124 and the BSC 126 are part of a Base
Station System 120. As shown in FIGURE 1, the BSC 126 is coupled to a Serving
Mobile Location Center (SMLC) 130. An SMLC controls location services by managing

the resources required to perform positioning of an MS. In alternative configurations, the SMLC may be operatively coupled through other elements (not shown) in the wireless communication system.
[0020] The MS 110 may receive signals, such as GPS signals, from one or more satellites 172,174 via communication links 156,158. Although two satellites are illustrated by way of example, only one satellite, or more usually, a plurality of satellites, may be employed when providing location services to a mobile station in a wireless communication system. Satellite data may also be received by other receivers (not shown) in the communication service provider network 140. Persons skilled in the communication arts will understand that GPS location systems for wireless systems generally include elements such as stationary GPS receivers and/or Wide Area Reference Networks for receiving satellite signals and providing reference data to SMLCs. The BSC 126 is coupled to the communication service provider network 140 to receive and transmit data such as audio/video/text communication and programming data, position requests, etc. One example of a communication service provider network is a Public Land Mobile Communication System Network (PLMN) operating under GSM.
[0021] FIGURE 2 shows another exemplary communication system 200 capable of providing location services, illustrated in functional block form. For simplicity, only one GPS satellite 272, and its associated broadcast signal link 252, is illustrated, f 0022J As shown in FIGURE 2, the MS 210 includes a central processing unit (CPU) 212, a memory 214, a User Interface 213, a Subscriber Identity Module (SIM) 215, and a transceiver 216. The term "CPU", as used throughout this description, is intended to encompass any processing device, alone or in combination with other devices (such as a memory), capable of controlling operation of a device (such as an SMLC 230 or the MS 210, or a portion thereof) in which it is included. For example, a CPU can include microprocessors, embedded controllers, application specific integrated circuits (ASICs), digital signal processors (DSPs), state machines, dedicated discrete hardware, and the like. The system, apparatus, and method described herein are not limited to the specific hardware component described or by any specific hardware component selected to implement the CPU 212.

[0023 J The transceiver 216 enables transmission and reception of data, such as audio/video/text communication and programming data, between the MS 210 and a remote location, such as the BTSs 224 and 226, or GPS satellites such as the satellite 272. An antenna 218 is electrically coupled to the transceiver 216. The basic operation of the MS 210 for voice and data communication is well-known in the art and is not described in detail herein.
[0024J As shown in FIGURE 2, the system 200 includes a SMLC 230 having a memory 234, and a CPU 232. The CPU 232 controls the operation of the SMLC 230 according to programmed instructions and data stored in the memory 234. The memories 214 and 234 may include read-only memory (ROM) components, random-access memories (RAM), and non-volatile RAM components. The memory 234 stores and provides instructions and data for the CPU 232. The memory 214 stores and provides instructions and data for the CPU 212. The components of the SMLC 230 are linked together by an internal bus system 236. The components of the MS 210 are linked together by an internal bus system 219.
[0025] As described in more detail below, the SIM 215 includes a unique MS identifier (MS ID), such as an International Mobile Subscriber Identity (EMSI), Mobile Subscriber Integrated Services Directory Number (MSISDN), or other MS ID. The MSI and MSISDN are unique identifiers for an MS, and either may be used. The MS ID (typically an IMSI, although the MSISDN or other MS IDs may be employed) may be retrieved by the CPU 212, encoded according to programmed instructions and data stored in the memory 214, incorporated into an RRLP Measure Position Response message or a Protocol Error message, and conveyed to the SMLC 230 via the communication links and system components illustrated in FIGURE 2. [0026] The User Interface 213 may be used to control the setting of a test mode parameter, as described below. In one exemplary embodiment, the User Interface may include a graphical user interface (GUI), and input devices such as a touch screen, pointing device or keypad. In another exemplary embodiment, the test mode parameter may be controlled using a proprietary command received through a connection (e.g., a serial connection, not shown) to a local device (not shown), such as a laptop computer or personal digital assistant, wherein the local device is operatively connected to the CPU 219.

f0027] As shown in FIGURE 2, the communication system 200 includes a BSS 220, which, in turn, includes a BSC 222 and a plurality of BTSs such as the BTSs 224,226. The BTSs permit the transmission and reception of data (such as audio/video/text and programming data) between the BSC 222 and remote locations, such as the MS 210, or GPS satellites, such as satellite 272. Antennas 228 and 229 are electrically coupled to the BTSs 224 and 226, respectively, in known manner. The MS 210 communicates with the BTSs via wireless links such as the wireless link 272. Additional radio links (not shown) may be used to transmit signals between the MS 210 and the BTS 224 or other BTSs (not shown). The basic operation of the BSC 222 and BTSs 224,226 is well-known in the art and therefore is not described in more detail herein. The BSC 222 is connected to the Communication Service Provider Network 240. The BSC 222 receives and transmits data, such as audio/video/text communication and programming data, position requests, or position data from the Communication Service Provider Network 240.
[0028] The BSC 220 is also coupled to the SMLC 230 in order to transmit and receive data relating to LCS. Examples of such data are described in detail below. [0029] RRLP LCS Messages Exchanged between the MS and the SMLC [0030] Figure 3 illustrates the flow of RRLP messages that may be exchanged between a test MS 310 and an SMLC 330 during a position request procedure. This procedure is described in greater detail in the reference 3GPP TS 04.31 V8.10.0. [0031] The RRLP Assistance Data message 342, RRLP Protocol Error message 346, and RRLP Assistance Data Acknowledgement message 348 enable the SMLC to transmit assistance data to the MS relating to position measurement and/or MS location calculation when RRLP downlink pseudo-segmentation is used (according to well known art, as described in 3 GPP TS 04.31 V8.10.0). If pseudo-segmentation is not used, the position request procedure skips the messages 342, 346 and 348. The RRLP Assistance Data message 342, the RRLP Protocol Error message 346, and the RRLP Assistance Data Acknowledgement message 348 may also enable the SMLC to transmit assistance data requested by the MS. In this case messages 352, 354 and 356 are skipped.
[0032] Using the RRLP Assistance Data message 342, or the RRLP Measure Position Request message 352, the SMLC transmits the Assistance Data component to the MS.

This component includes assistance data for location measurement and/or location
calculation.
[0033] The MS transmits an RRLP message containing the Protocol Error component to
the SMLC using the RRLP Protocol Error message 346. This message is sent only if
there is a problem that prevents the MS from receiving a complete and understandable
Assistance Data component (the contingent aspect of the message is signified in the
FIGURE 3 by using a dashed line). The Protocol Error message 346 includes an optional
information element referred to as an extension container. As described below in more
detail, the extension container of the Protocol Error message 346 may be adapted to
convey the MS ID (e.g., MSI or MSISDN) of the MS to the SMLC. This message is
conveyed when there is a protocol error. Consequently, as described below, subsequent
messages may be utilized for MS identity conveyance.
[0034J When the MS has received the complete Assistance Data component, it transmits
the RRLP, Assistance Data Acknowledgement message 348, to the SMLC.
[0035] The SMLC transmits the Measure Position Request component to the MS using
the RRLP Measure Position Request message 352. This component includes Quality of
Service (QoS), other instructions, and possible assistance data.
[0036] The MS transmits an RRLP message containing the Protocol Error component to
the SMLC using the RRLP Protocol Error message 354. This message is transmitted
only if there is a problem that prevents the test MS from receiving a complete and
understandable Measure Position Request component. The Protocol Error message 354
also includes an optional extension container that may be adapted to convey the MS ID
(e.g., MSI or MSISDN) of the MS to the SMLC. However, this message is conveyed
only if an error is encountered. Consequently, the subsequent message described below
maybe utilized to convey,MS identity.
[0037] The MS attempts to report the requested location measurements using the RRLP
Measure Position Response message 356. Examples of location measurements may
include a position estimate, AGPS measurements, or a measurement error. When the
MS has location measurements, position estimate, or an error indication
(measurements/location estimation not possible), it transmits the results in the Measure
Position Response component to the SMLC.

[0038] The RRLP Measure Position Response message 356 also includes an optional extension container that may be adapted to convey the MS ID (e.g., IMSI or MSISDN) of the MS to the SMLC. If the position determination process has not been previously aborted due to an error, the extension container of this message may be implemented in order to convey the MS ID to the SMLC. If the process is aborted prior to this message, then one of the Protocol Error messages 346 or 354 may used instead.
Extension Container Specification
[0039] The RRLP extension container is exported from the Mobile Application Part (MAP) Extension Data Types (described in detail in the incorporated 3GPP TS 29.002 V3.h.O reference). As a result, its specification complies with the MAP Abstract Syntax Notation One (ASN.l) description rules. For the actual field encoding/decoding, the Packed Encoding Rules (PER) PER apply (e.g., bitmap for optional parameters, extension indicator when the ellipsis notation is used, etc). As described below, the MAP compliant encoding involves object identifiers, which were either previously registered or are yet to be registered.
[0040] An exemplary ASN-1 encoding of the extension container is given in the pseudo-code below. MAP-EXTENSION ::= CLASS {
&ExtensionType
OPTIONAL,
&extensionId OBJECT IDENTIFIER }
ExtensionContainer ::= SEQUENCE {
privateExtensionList [0]PrivateExtensionList
OPTIONAL,
pcs-Extensions [l]PCS-Extensions OPTIONAL,
...}
PrivateExtensionList ::= SEQUENCE SIZE (L.maxNumOfPrivateExtensions) OF
PrivateExtension
maxNumOfPrivateExtensions INTEGER ::= 10

PrivateExtension ::= SEQUENCE {
extld MAP-EXTENSION.&extensionld
({ExtensionSet}),
extType MAP-EXTENSION.&ExtensionType
({ExtensionSet} {@extld}) OPTIONAL}
[0041] In accordance with one embodiment, the MS identification may be encoded in the extType variable. The optional PCS-Extensions are not included in this exemplary embodiment. The OI should not be confused with the IMSI or other MS ED which may be used to identify the test MS. The content of the OI, or the OI "value", is preceded by a length indicator that provides the number of octets of the OI value. [0042] As described in the incorporated references, the ASN-1 OI enables unambiguous identification of an entity that is registered in a worldwide tree. The properties of OIs are well known to persons skilled in the art of wireless communications, and therefore are not described in more detail herein. OIs may be registered through an appropriate organization or registration authority. An example of an existing OI registration, similar to that which would be suitable for an exemplary embodiment, is the one assigned for the ASN-1 BASIC-PER, UNALIGNED variant: {joint-iso-itu-t asnl (1) packed-encoding (3) basic ( O ) unaligned (1)} "Packed encoding of a single ASN.l type (basic unaligned)." A suitable OI may be represented by the known PER hexadecimal format and used for the "extld" entry of the exemplary ASN-1 encoding of the extension container shown above. For this example, the OI is represented by the decimal numbers "1,3, 0,1", which may be encoded by the PER hexadecimal sequence 0x03, 0x2b, 00, 01 (0x03 is the variable length value of 3 octets; 0x2b represents the value 43 = 40*1 + 3).
[0043] In one embodiment, the "ectype" variable is the component containing the private extension data that may be used to convey the IMSI or other MS ID for the test MS. It is an ASN-1 open type, therefore it has a length determinant followed by a field list. For the current example, the length of the private extension may be selected not to exceed 128 octets. The length determinant may therefore be encoded in one octet, or in 8 bits, hi one embodiment, the field list for the extType variable may have the following format:

FieldList ::= SEQUENCE {
testExtRevision TestExtensionRevision,
imsi IMSI,
• • •
}
[0044] In the example above, the following notes apply: The ellipsis notation "..." indicates that extensions can be added. If the test MS in some exceptional case cannot provide its IMSI, the IMSI field may be filled with zeros. The TestExtension Revision is an integer variable having a value between 0 and 63, inclusive, and may be represented by a 6-bit hexadecimal number. The IMSI variable is an octet string with a fixed size of 8 octets.
[0045] TABLE 1 is an exemplary extension container encoding in accordance with the teachings above:

Test MS Identification by the SMLC and Exemplary Operation {0046] In one exemplary embodiment, a test MS is configured to encode its associated MS ID (e.g., MSI or MSISDN) in an extension container of the Measure Position Response message 356, or in an extension container of the Protocol Error messages 346 and 354 (FIGURE 3). As described above, the Measure Position Response message is transmitted to an SMLC to report a position determination, AGPS measurements, or a measurement error. The Protocol Error messages are transmitted by the test MS to an SMLC to report a protocol error. The SMLC is configured to decode the extension container, retrieve the MS ID, and store the MS ID in association with a unique positioning session identifier that may belong to a plurality of position session identifiers maintained by the SMLC.
[0047] When attempting to decode a private extension, the SMLC may first attempt to decode the 01. If the received OI is not recognized, the SMLC may attempt to skip the OI and decode the length of the open type variable in order to skip the entire private extension container. If the extension container prevents proper decoding of the RRLP message, the SMLC may transmit a RRLP Protocol Error message to the MS and terminate the position determination session with the BSC. [0048] Whenever the SMLC detects that the length determinant of the OI, or of the ExtType, is encoded with a value indicating that the length is greater than 16K, the SMLC transmits a protocol Error message to the MS. The SMLC terminates the position determination session with the BSC.
[0049J Advantageously, the MS may be configured with a test mode parameter. The test mode parameter may be set with the values "test mode on" (abbreviated "ON") and "test mode off' (abbreviated "OFF"), where the default value is "OFF." In the MS, the configuration is done through a proprietary command using a serial link into the phone or via the MS user interface (UT). Encoding of the MS ID in a message extension container is activated at the test MS only when the test mode parameter is set to "ON." In one embodiment, encoding of the MS ED in the extension container is activated at the test MS only when the test mode parameter is set to "ON."
[0050J FIGURE 4 is a flowchart diagram illustrating steps in an exemplary method. At a STEP 402, an MS receives a message from an SMLC. Exemplary messages may include

an RRLP Assistance Data message or an RRLP Measure Position Request Message. The
method proceeds to a STEP 404.
[0051] Optionally, the MS may be equipped with a test mode parameter. If the MS is
programmed to encode the MS ID and does not have a test mode parameter, then the
STEP 404 maybe skipped and the method proceeds directly to a STEP 406. If the test
mode parameter is included in the MS, and it is set to ON, the concept also proceeds to
the STEP 406. If the MS is not programmed to send an MS ID, or if the test mode
parameter is set to OFF, the method proceeds to a STEP 408.
[0052J At the STEP 406, the MS encodes its associated MS ID in an extension
container of a suitable response message, such as the Measure Position Response
message 356 (FIGURE 3), the Protocol Error messages 346 and 354. Suitable messages
may include any messages having an extension container. Other messages that may be
sent that do not have an extension container, such as the Assistance Data
Acknowledgement message, are not employed for encoding the MS ID, and are not
referred to by the steps shown in FIGURE 4. The method proceeds to a STEP 408.
[0053] At the STEP 408 the MS transmits the suitable response message to the SMLC,
and proceeds to a STEP 410.
[00541 At the STEP 410 the SMLC processes the suitable response message and
proceeds to a STEP 412.
[0055] At the STEP 412, if the SMLC is appropriately configured to retrieve the MS ID
from the extension container, the method proceeds to a STEP 414. If the SMLC fails to
retrieve the MS ID, the method proceeds to a STEP 416. If no MS ID was sent (e.g., the
test mode was set to OFF), the method also proceeds to the STEP 416.
[0056] At the STEP 414, the SMLC stores the MS ID in association with a unique
positioning session identifier for reference by test engineers as needed, and then
continues normal processing functions.
[0057] At the STEP 416, the SMLC may respond by transmitting an RRLP Protocol
Error message to the MS, and terminating the position determination session with the
BSC, before continuing with normal processing functions. Alternatively, if the MS did
not send an MS ID (e.g., the test mode was OFF) the SMLC will also continue with
normal processing functions at the STEP 416. As another possibility, the SMLC may
transmit an RRLP Protocol Error message to the MS without terminating the position

determination session with the BSC, before continuing with normal processing functions. These possible responses by the SMLC are discussed further below. [0058] Several advantageous novel aspects exist. For example, the implementation of a private extension only impacts operation of the MS and the SMLC. It does not impact the operation of other network elements such as the BSS, the BSC or the Mobile Switching Center (not shown in the FIGURES). The MS identification method and apparatus does not impact other elements because RRLP messages are passed transparently by the BSC, and only the size of the RRLP message is a factor for the BSC processing of the message.
[0059] Another advantageous aspect relates to the interoperability between a test MS and a "naive" SMLC (i.e., an SMLC that is not configured for operation in a test mode according to the teachings herein). If an SMLC is unable to decode the extension container (e.g., as could occur with a roaming situation, although roaming would be an atypical circumstance for operation of a test MS), several possibilities may occur: 1) when the naive SMLC detects the presence of the optional extension container, it may choose not to attempt to decode the message and may transmit a Protocol Error message in response; 2) when the extension container is at the end the message, the naive SMLC may attempt to decode the message, but stop the decoding upon reaching the extension container, thereby processing the part of the message decoded before reaching the extension container; 3) the naive SMLC maybe capable of decoding extension containers, but decides to discard private extensions for which it does not recognize the 01. For the cases 2) and 3) above, positioning operability is maintained. However, for case 1) above the test MS will not have positioning operability unless the test mode parameter is implemented and set to "OFF".
[0060] Yet another advantageous feature relates to the size of the RRLP Measure Position Response message. The addition of a private extension increases the size of the RRLP payload, which may be an issue in terms of segmentation, especially for the RRLP Measure Position Response message. However, if the message size remains under 252 octets, no uplink segmentation is required. The exemplary embodiment described above limits the increase in the size of the RRLP message to 128 octets (120 octets is the typical number for reporting one set of GPS measurements associated with

16 satellites) or less, reducing the possibility that the complete RRLP message will exceed 252 octets.
[0061] Those of ordinary skill in the communications and computer arts shall recognize that computer readable medium that tangibly embodies the method steps of any of the embodiments described herein may be used in accordance with the present teachings. Such a medium may include, without limitation, RAM, ROM, EPROM, EEPROM, floppy disk, hard disk, CD-ROM, etc. The disclosure also includes the method steps of any of the foregoing embodiments synthesized as digital logic in an integrated circuit, such as a Field Programmable Gate Array, or Programmable Logic Array, or other integrated circuits that can be fabricated or modified to embody computer program instructions.
[0062] The Mobile Stations 110 and 210, in accordance with the present teachings may include, without limitation: a wireless telephone, a personal digital assistant with wireless communication capabilities, a laptop having wireless communication capabilities, and any other mobile digital device for personal communication via wireless connection.
[0063] A number of embodiments have been described. Nevertheless, it will be understood that the methods described herein may be executed in software or hardware, or a combination of hardware and software embodiments. As another example, it should be understood that the functions described as being part of one module may, in general, be performed equivalently in another module. As yet another example, steps or acts shown or described in a particular sequence may generally be performed in a different order, except for those embodiments described in a claim that include a specified order for the steps.

CLAIMS
1. A location services testing method for use in a wireless communication system,
comprising the steps of:
a) receiving a first location services message at a Mobile Station (MS);
b) encoding a unique MS identifier in an extension container of a second location services message;
c) transmitting the second location services message to a Serving Mobile Location Center (SMLC), responsive to the first location services message, wherein the SMLC maintains a plurality of positioning session identifiers;
d) decoding the extension container thereby retrieving the unique MS identifier; and
e) storing the unique MS identifier corresponding to and associated with a unique positioning session identifier belonging to the plurality of positioning session identifiers.

2. The location services testing method of Claim 1, wherein the first location services message is a Radio Resource Location Services (LCS) Protocol (RRLP) Assistance Data message.
3. The location services testing method of Claim 1, wherein the first location services message is an RRLP Measure Position Request message.
4. The location services testing method of Claim 1, wherein the unique MS identifier is an International Mobile Subscriber Identity.
5. The location services testing method of Claim 1, wherein the unique MS identifier is a Mobile Subscriber Integrated Services Directory Number.
6. The location services testing method of Claim 1, wherein the step of encoding the unique MS identifier further includes the step of setting a test mode parameter that controls the encoding of the unique MS identifier.
7. The location services testing method of Claim 1, wherein the second location services message is an RRLP Protocol Error message.
8. The location services testing method of Claim 1, wherein the second location services message is an RRLP Measure Position Response message.
9. A system for testing location services in a wireless communication system, comprising:

a) a mobile station (MS) capable of performing location services functions,
wherein the MS includes:
i) a transceiver, adapted to receive a first location services message, and adapted to transmit a second location services message; and ii) an MS CPU, operatively coupled to the transceiver, wherein the MS CPU receives the first location services message, and wherein the MS CPU encodes an MS identifier uniquely identifying the MS, and wherein the MS CPU inserts the unique MS identifier in an extension container of the second location services message;
b) a Base Station System (BSS), wherein the BSS includes a Base Transceiver Station (BTS) adapted to transmit the first location services message to the MS and adapted to receive the second location services message from the MS; and
c) a Serving Mobile Location Center (SMLC) that controls the location services for the wireless communication system, wherein the SMLC maintains a plurality of positioning session identifiers, and wherein the SMLC includes:
i) an SMLC CPU, operatively coupled to the BSS, wherein the SMLC CPU outputs the first location services message and transmits the first location services message to the BSS, and wherein the SMLC CPU receives the second location services message from the BSS and decodes the extension container of the second location services message thereby retrieving the unique MS identifier; and
ii) a memory, coupled to the SMLC CPU, wherein the memory stores the unique MS identifier corresponding to and associated with a unique positioning session identifier among the plurality of positioning session identifiers,
10. The system for testing location services of claim 9, wherein the MS CPU includes a test mode parameter, and wherein the MS CPU encodes the MS identifier and inserts the unique MS identifier in an extension container responsive to a setting of the test mode parameter.
11. The system for testing location services of claim 10, wherein the MS includes a User Interface, and wherein the User Interface is coupled to the MS CPU to control the setting of the test mode parameter.

12. The system for testing location services of claim 9, wherein the second location services message is a Radio Resource Location Services (LCS) Protocol (RRLP) Measure Position Response message.
13. The system for testing location services of claim 9, wherein the second location services message is an RRLP Protocol Error message.
14. The system for testing location services of claim 9, wherein the first location services message is an RRLP Assistance Data message.
15. The system for testing location services of claim 9, wherein the first location services message is an RRLP Measure Position Request message.
16. The system for testing location services of claim 9, wherein the MS includes a Subscriber Identity Module ((SIM) that stores the unique MS identifier.
17. The system for testing location services of claim 9, wherein the unique MS identifier is an International Mobile Subscriber Identity.
18. The system for testing location services of claim 9, wherein the unique MS identifier is a Mobile Subscriber Integrated Services Directory Number.
19. A system for testing location services in a wireless communication system, comprising:

a) means for receiving a first location services message;
b) means for encoding a unique MS identifier in an extension container of a second location services message;

c) means for transmitting the second location services message to a Serving Mobile Location Center (SMLC), responsive to the first location services message, wherein the SMLC maintains a plurality of positioning session identifiers;
d) means for decoding the extension container of the second location services message thereby retrieving the unique MS identifier; and
e) means for storing the unique MS identifier corresponding to and associated with a unique positioning session identifier among the plurahty of positioning session identifiers.
20. A computer program executable on a general purpose computing device, wherein
the program is capable of performing location services testing in a wireless
communication system comprising a plurality of mobile stations and a plurality of base
stations, comprising:

a) a first set of instructions for receiving a first location services message at a
Mobile Station (MS);
b) a second set of instructions for encoding a unique MS identifier into an
extension container of a second location services message;
c) a third set of instructions for transmitting the second location services message
to a Serving Mobile Location Center (SMLC), responsive to the first location services
message, wherein the SMLC maintains a plurality of positioning session identifiers;
d) a fourth set of instructions for decoding the extension container thereby
retrieving the unique MS identifier; and
e) a fifth set of instructions for storing the unique MS identifier corresponding to
and associated with a unique positioning session identifier belonging to the plurality of
positioning session identifiers.

Documents:

3556-chenp-2005 abstract duplicate.pdf

3556-chenp-2005 claims duplicate.pdf

3556-chenp-2005 description(complete) duplicate.pdf

3556-chenp-2005 drawings duplicate.pdf

3556-chenp-2005-abstract.pdf

3556-chenp-2005-assignement.pdf

3556-chenp-2005-claims.pdf

3556-chenp-2005-correspondnece-others.pdf

3556-chenp-2005-description(complete).pdf

3556-chenp-2005-drawings.pdf

3556-chenp-2005-form 1.pdf

3556-chenp-2005-form 26.pdf

3556-chenp-2005-form 3.pdf

3556-chenp-2005-form 5.pdf

« Previous Patent

Next Patent »

Patent Number

231250

Indian Patent Application Number

3556/CHENP/2005

PG Journal Number

13/2009

Publication Date

27-Mar-2009

Grant Date

04-Mar-2009

Date of Filing

27-Dec-2005

Name of Patentee

QUALCOMM INCORPORATED

Applicant Address

5775 MOREHOUSE DRIVE, SAN DIEGO, CALIFORNIA 92121,

Inventors:

#	Inventor's Name	Inventor's Address
1	ARCENS, SUZANNE	1760 HALFORD AVENUE, #365, SANTA CLARA, CA 95051,

PCT International Classification Number

H04Q 7/00

PCT International Application Number

PCT/US04/10576

PCT International Filing date

2004-04-06

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	60/483,212	2003-06-27	U.S.A.