Note: Descriptions are shown in the official language in which they were submitted.
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
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
I. 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 Apt
[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.
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
2
[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Ø
[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 04.31
V8.10.0), July, 2002. The reference is referred to hereinafter as 3GPP TS
04.31 V8.10Ø
[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Ø
[0007] A wireless communications network, such as the Public Land Mobile
Communications Network (PLMN) 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
m) such
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
3
as an International Mobile Subscriber Identity (IMSI) 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 (IMSIJ, 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 II7, and store the MS ID in association with 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,
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
4
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
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
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 audiolvideo/text communication and
programming
data, position requests, etc. One example of a communication service provider
network
is a Public Land Mobile Communication System Network (PLMI~ 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.
[0022] 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 anyspecific hardware component selected to
implement the CPU 212.
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
6
[0023] 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 21 S 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.
[0024] 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 (lMSlJ, Mobile
Subscriber
Integrated Services Directory Number (MSISDN), or other MS ID. The IMSI and
MSISDN are unique identifiers for an MS, and either may be used. The MS 1D
(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.
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
7
[0027] 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
audiolvideo/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 audiolvideo/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Ø
[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 andlor MS
location
calculation when RRLP downlink pseudo-segmentation is used (according to well
known art, as described in 3GPP 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 RRT.P 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 R.RLP Assistance Data message 342, or the RRLP Measure
Position
Request message 352, the SMLC transmits the Assistance Data component to the
MS.
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
8
This component includes assistance data for location measurement andlor
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 m (e.g., IMSI or MSISDI~ 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
[0034] 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., IMSI or MSISDl~ of the MS to the SMLC. However, this message is
conveyed
only if an error is encountered. Consequently, the subsequent message
described below
may be utilized to convey~.VIS 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.
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
9
[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.0 reference). As a result, its specification complies with the MAP
Abstract Syntax
Notation One (ASN.1) 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 f
privateExtensionList [0]PrivateExtensionList
OPTIONAL,
pcs-Extensions [1]PCS-Extensions OPTIONAL,
...'~
PrivateExtensionList ::= SEQUENCE SIZE (l..maxNumOff'rivateExtensions)
OF
PrivateExtension
maxNumOfPrivateExtensions INTEGER ::=10
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
PrivateExtension ::= SEQUENCE ~
extId MAP-EXTENSION.&extensionId
( f ExtensionSet}),
extType MAP-EXTENSION.&ExtensionType
({ExtensionSet} f @extId})
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 ID 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.1
type (basic
unaligned)." A suitable OI may be represented by the known PER hexadecimal
format
and used for the "extId" 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, Ox2b,
00,
O1 (0x03 is the variable length value of 3 octets; Ox2b represents the value
43 = 40* 1 +
3).
[0043] In one embodiment, the "extType" 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. In one embodiment, the field list for the extType variable may have
the following
format:
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
11
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 1MSI 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:
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
12
Table 1- Exemplary Extension Container Encoding
Field Value Field Comments
Length
Start ExtensionContaitaer
Extension indicator 0 1 bit Extensible component,
preamble but no extension
present
Optional Parameter bitmap10 2 bits PrivateExtensionList is
present. pcs-
Extensions is absent.
Number of private extensions1 to 4 bits Range of encoded value
10 is:(10-1) and 9 is
1001b (binary encoding
on 4 bits).
For this exemplary embodiment,
the
number of private extension
will be 1.
Start PrivateExtension First (and last) private
(#1) extension
Optional Parameter bitmap1 1 bit Indicates whether the
extType optional
parameter is present (The
value 1
indicates that it is present).
Start extld It is an OI which contains
a length field
and a value field.
Object Identifier Length 8 bits The length is encoded
on one octet.
For this example the number
of octets in
the OI value is 3, therefore
the length is
encoded by the PER hexadecimal
number 0x03.
Object Identifier value In the present example
the OI value is
(1,3,01) and is encoded
by the PER
hexadecimal sequence Ox2b
00 01 (Ox2b
is for 43 = 40*1 + 3).
Start extType
Length determinant Ob7b6...8 bits For the present example
the binary
b1 encoding of the length
determinant is:
0000 0010b (binary value)
Start value of extType This is the open type
bit field.
Extension marker 0 1 bit No extension...yet.
TestExtRevision 0 6 bits It identifies the revision
number of the
test extension. The initial
value is 0.
This way, a new parameter
does not
have to be added as an
extension (using
the extension preamble).
The addition of
a new parameter can rely
on the test
extension revision.
IMSI value 8 octets15 BCD digits - If the
1MSI is less than 15
digits, the extra digits
are encoded l l l 1b
(binary value)
Padding 0 1 The total length of the
private extension bit
field, without any padding
is 15 bits. So one
bit of padding is necessary
to reach the 2
octets boundary.
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
13
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., IMSI 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 OI. 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.
[0049] 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 (Un. Encoding of the MS B7 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 ID in the extension container is
activated at the
test MS only when the test mode parameter is set to "ON."
[0050) 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
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
14
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 may be 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.
[0052] 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.
[0054] 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
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
determination session with the BSC, before continuing with normal processing
functions. These possible responses by the SMLC are discussed fiuther 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 may be capable of decoding extension
containers, but decides to discard private extensions for which it does not
recognize the
OI. 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
CA 02530359 2005-12-21
WO 2005/011308 PCT/US2004/010576
16
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.
