Note: Descriptions are shown in the official language in which they were submitted.
CA 02336086 2000-12-22
WO 00/01193 PC'T/SE99/00925
SYSTEM AND METHOD OF PROVIDING
A MENU TO USERS OF MOBILE STATIONS
IN A RADIO TELECOMMUNICATIONS NETWORK
BACKGROUND OF THE INVENTION
This invention relates to radio telecommunications and, more particularly, to
a system
and method in a radio telecommunications network of providing a menu to users
of
mobile stations.
Deccrintion of Related art
As the number of services increases in radio telecommunications networks,
subscribers are overwhelmed by the many services offered. In certain radio
telecommunications networks, to access services, subscribers dials a feature
code
corresponding to a service. In some cases, the feature code must be
accompanied by
1 S additional information, which must be entered in a predetermined format to
activate
the service. Because often subscribers only use many of these services rarely,
some
subscribers find it difficult to remember the feature code and the correct
format of the
additional information required to use the services. Therefore, many, perhaps
most,
subscribers use only a limited number of services, and thus, do not benefit
from the
scope of services available to them.
An example of a service using feature codes is the mufti-party calling service
offered by the Digital Advanced Mobile Phone System (D-AMPS) and by the Global
System for Mobile Communications (GSM). The mufti-party calling service offers
the possibility of establishing a call in which there are at least three
parties: a calling
party, a called party, and one or several conferencing parties. A problem with
the
mufti-party service of both D-AMPS and GSM is the cumbersome and difficult
user
interface these services provide. In both cases, the subscriber must remember
and
enter a number of codes in order to implement and control the conferencing.
When
two subscribers are engaged in a telephone call, and desire to add a third
subscriber to
the conference, the first subscriber must first enter a code to place the
second
subscriber on hold. The first subscriber then dials the third subscriber's
telephone
CA 02336086 2000-12-22
WO 00/01193 PCT/SE99/00925
-2-
number to establish a call with that subscriber. The first subscriber must
then
remember another code and enter that code to establish the three-way
connection
between the three subscribers. In addition, the subscribers may utilize the
flash feature
on their mobile phones to selectively place the other subscribers in either
speech or
idle mode.
To overcome certain drawbacks of the access to services through feature codes,
certain telecommunications networks, such as GSM, offer subscriber service
management by providing mobile stations with a pull up menu on the mobile
station's
display for the services to which the subscriber has subscribed. Examples of
such
services are Call Forwarding, Call Waiting, and Speed Dialing. The subscriber
may
scroll down to the appropriate service, and change the state of the selected
service by
activating, deactivating, or entering required subscriber information with the
mobile
station's keypad. The mobile station then transmits the updated information
via
Unstructured Supplementary Services Data (USSD) messages to the Public Land
Mobile Network (PLMN) to actually update the state of the selected feature.
USSD
is utilized to transport unstructured or system unrecognizable data (e.g.,
user specified
character messages) using a non-traffic channel for communicating application-
layer
data between a mobile station and the PLMN.
The GSM subscriber service management menu, however, is hard-coded in the
mobile station, and cannot be changed. Therefore, GSM lacks the flexibility to
upgrade menus or add new menus at the network level without replacing the
mobile
stations. In addition, when a subscriber purchases a new mobile station, it
may not
have the same menus as the subscriber's old mobile station or the same menus
as other
subscriber's have in a mufti-party call. Such inconsistencies tend to create
confusion
among subscribers. Thus, fiirther discouraging the subscribers from using new
advanced services.
From the foregoing it will be apparent that there is still a need in radio
telecommunications systems for a way to provide a menu to mobile stations in
radio
telecommunications network with more flexibility.
CA 02336086 2000-12-22
PCT/SE99/00925
The Swedish Patent Otflce 21.07.2000
PCT intemationai Application
-3-
SUMMARY OF THE INVENTION
In a preferred embodiment, the present invention provides a radio
telecommunications system and a method for generating menus at the network
level
and providing those menus to mobile subscribers. These menus provide powerful
user
interfaces for advanced services provided by the radio telecommunications
system.
Because, the menus are generated at the network level and transmitted to the
subscribers' mobile stations, the invention provides a flexible solution.
In one embodiment, the radio telecommunications system according to the
present invention provides menus generated at the network level to mobile
subscribers.
A node of the system, the cooperating node, has a menu generator for
generating a
menu message that includes menu data, and a menu sender for sending the menu
message to a mobile station in the telecommunications system. The cooperating
node
also has a selection receiver for receiving a selection message, which
includes a menu
selection made by the mobile subscriber. Furthermore, the cooperating node has
a
selection performer for perforniing the menu selection.
Another component of the invention is a mobile station, having means for
determining whether it can accept the message or not, and means for notifying
the
coordinating node if the menu message is rejected. The mobile station further
includes
a menu message receiver for receiving the menu message and displaying the menu
data on a display screen, and a menu selector for obtaining the menu selection
from
the mobile subscriber. The mobile station also has a selection message
generator for
generating the selection message including the menu selection, and a selection
message sender for sending the selection message to the cooperating node.
In another embodiment, the present invention is a method in a radio
telecommunications network of providing a menu to a mobile subscriber. The
method
generates in a cooperating node a menu message including menu data. Then, the
menu
message is sent to a mobile station, which determines whether the message is
acceptable. Upon receipt of the menu message by the mobile station, if the
message
is determined to be acceptable, the menu data is displayed on a display
screen, and a
menu selection is obtained from the mobile subscriber. Then, a selection
message,
Amended Sheet
CA 02336086 2000-12-22
PCT/SE99/00925
21.07.2000
-3a-
including the menu selection, is generated by the mobile station and sent to
the
cooperating node. The selection message is received in the cooperating node,
and the
menu selection is performed at the cooperating node.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will be better understood and its numerous objects and
Amended Sheet
CA 02336086 2000-12-22
WO 00/01193 PCT/SE99/00925
advantages will become more apparent to those skilled in the art by reference
to the
following drawings, in conjunction with the accompanying specification, in
which: '
FIGURE 1 is a schematic diagram of a radio telecommunications network;
FIGURE 2 is schematic diagrams illustrating respectively components of a
cooperating node and components of a mobile station in accordance with the
present
invention;
FIGURE 3 is a message flow diagram illustrating the flow of messages in
accordance with a first preferred embodiment of the present invention;
FIGURE 4 is a block diagram illustrating the relationship between a
MenuDeliver message of FIGURE 3, menu data displayed on a mobile station
display,
and a MenuSelection message of FIGURE 3 in accordance with the teachings of
the
present invention;
FIGURE 5 is a message flow diagram illustrating the flow of messages in
accordance with a second preferred embodiment of the present invention;
FIGURE 6 is a message flow diagram illustrating the flow of messages in
accordance with a third preferred embodiment of the present invention;
FIGURE 7 is a simplified schematic diagram of a radio telecommunications
network in accordance with a fourth preferred embodiment of the present
invention;
FIGURE 8 is an illustration of the mapping of menu data in an IS-136 R-Data
MenuDeliver message in accordance with the teachings of the present invention;
and
FIGURE 9 is an illustration of the mapping of menu data in an IS-136 R-
DATA MenuSelection message in accordance with the teachings of the present
invention.
DETAILED DESCRIPTION OF EMBODIMENTS
The present invention provides a radio telecommunications system and a
method for generating menus at the network level and providing those menus to
mobile subscribers. Hitherto advanced radio telecommunications services were
difficult for subscribers to access due to cumbersome user interfaces. While
static
menus in mobile stations have been know in prior art telecommunications
system,
these menus have not had the required flexibility to provide dynamic user
interfaces.
The menus provided by the present invention allow for powerful user
CA 02336086 2000-12-22
W~U 00/01193 PGT/SE99/00925
-S-
interfaces for advanced services provided by modern telecommunications
systems.
Because the menus are generated at the network level and transmitted to the
subscribers' mobile stations, the invention provides a flexible solution to
the problem
of giving subscribers user fi-iendly access to complex services.
Reference is now made to FIGURE 1, which is a schematic of a radio
telecommunications network 10 including a plurality of interconnected Mobile
Switching Centers (MSCs) I2. For illustrative purposes, only two MSCs 12 are
shown. It will be understood that the network 10 likely includes many more
interconnected MSCs 12.
The first and second MSCs 12 and 12' may comprise any one of a number of
known telecommunications switching devices, as commonly used and known in the
art for providing digital cellular telephone service to a plurality of mobile
stations
(MS) 16. The MSCs 12 are interconnected with each other for communication via
both voice trunks 11 (illustrated with broken lines) and signaling links 15
(illustrated
with solid Lines) providing a known ISUP (or R1 or R2} type connection. The
voice
flunks 11 provide voice and data communications paths used to carry subscriber
communications between the MSCs 12. The signaling links I S carry command
signals between the MSCs 12. These signals are used, for example, in setting
up and
tearing down voice and data communications over the voice trunks 11 and
controlling
the calling services provided by the MSC to the MSs 16.
The MSCs 12 are also connected to a home location register (HLR) 20 by
means of signaling links 17. That connection may be a known Mobile Application
Part (MAP) or IS-41 type connection or a connection according to any other now
known or future protocol. The HLR 20 stores information concerning the MSs 16,
such as location information and service information. The HLR 20 may fiuther
be
associated with a service control point (SCP) to provide Wireless Intelligent
Network
(WIN) services, as known in the art. A subscriber record containing downloaded
portions of the HLR 20, as well as information received from the MSs 16
themselves,
is maintained in a visitor location register (VLR) associated with MSC 12.
In one implementation, the MSCs 12 are fiwther connected to at least one
associated base station controller (BSC) 13 via both a signaling link 19A and
a voice
trunk 21 A. To simplify the illustration, only one BSC is shown in Figure 1.
However,
CA 02336086 2000-12-22
WO 00/01193 PCT/SE99/009Z5
-6-
in actual implementations it is likely that several or many BSCs are connected
to an
MSC 12. The voice trunk 21A provides a voice and data communications path used
to carry subscriber communications between the MSC 12' and its associated BSC
13.
The signaling link 19A carries command signals between the MSC 12' and its
associated BSC 13. The BSC 13 is then connected to a plurality of base
stations (BS)
14 which operate to effectuate radio frequency communications with proximately
located MSs 16 over an air interface 18. The BSC 13 functions in a well-known
manner to control this radio frequency communications operation over signaling
links
19B and voice trunk Z1B.
In another implementation, the MSC 12 is connected directly to the plurality
of BS 14. The functionality provided by the BSC 13 in controlling the radio
frequency
communications operation is then instead performed by the MSC 12. The MSC 12
is
connected to the BS 14 via both a signaling link 19 and a voice trunk 21. The
voice
trunk 21 provides a voice and data communications path used to carry
subscriber
communications between the MSC 12 and its associated BS 14. The signaling link
19
carnes command signals between the MSC 12 and its associated BS 14.
Although direct communications links (signaling and/or trunk) are illustrated
in FIGURE 1, it is understood by those skilled in the art that the links are
not
necessarily direct links between the illustrated nodes, and may instead pass
through
many other communications nodes (not shown) of the radio telecommunications
network, and perhaps even utilize other communications networks (such as the
public
switched telephone network (PSTI~ 24). For example, the MSCs 12 may further be
connected to a gateway MSC (G-MSC) 22 through a voice trunk 25 and a signaling
link 23. In turn, the G-MSC 22 is connected to the PSTN 24 by a signaling link
26
and a voice trunk 27. Thus, the illustration of the links in the manner of
FIGURE 1
is therefore illustrative. The invention includes all alternative methods of
establishing
communications links.
The radio telecommunications network 10 is a Global System for Mobile
(GSM) communications, a D-AMPS system, a code division multiple access (CDMA)
system, or any other type of telecommunications system.
Reference is now further made to FIGURE 2, which is a schematic diagram
illustrating respectively components of a cooperating node and components of a
MS
CA 02336086 2000-12-22
WU 00/01193 PCT/SE99/009Z5
_7_
in accordance with the present invention. The present invention is a system
for
providing a menu to a MS used by a mobile subscriber in the radio
telecommunications network 10 such as shown on FIGURE 1. The system, according
to the present invention, generates menus at the network level and provides
these
menus to the MSs 16. Menus may be changed or upgraded at the network level and
provided to operating MSs 16 without modifying or replacing the MSs 16. A
cooperating node 30, which can be any node or combination of nodes in the
network,
forwards a menu to one of the MS 16 through the network of Figure 1. From the
menu
received by the MS, a subscriber selects the desired menu items. The MS 16
returns
the selection to the cooperating node 30 for further processing. Thus,
forwarding of
menus, return of the subscriber's selection, and performing that selection in
the
cooperating node is accomplished. Further, updating of the MS display screen
may
also be performed.
The system uses the cooperating node 30, which for instance may be the MSC
12, the HLR 20, the PSTN 24 or any other node, and at least one MS 16. The
cooperating node 30 has a menu generator 32 for generating a menu message
including menu data, and a menu sender 34 for sending the menu message from
the
cooperating node to the MS 16. The cooperating node 30 also has a selection
receiver
36 for receiving a selection message. The selection message includes a menu
selection
made by the mobile subscriber. The cooperating node 30 also includes a
selection
performer 38 for performing the menu selection in the cooperating node 30. The
cooperating node 30 may further include an update menu generator 40 for
generating
and sending an update message to the MS so as to update its display screen.
The
cooperating node 30 also includes a menu request receiver 42 for receiving a
menu
request message, and a menu trigger module 44 for detecting a need for a menu.
The
menu trigger 44, the menu generator 32, the selection perfornier 38 and the
update
menu generator 40 may for example consist of additional logic added to the
cooperating node. The menu request receiver 42, the selection receiver 36 and
the
menu sender 34 may consist, for example, of added logic to receivers (not
shown) of
the cooperating node.
The MS 16 in turn has a menu message receiver 50 for receiving the menu
message and displaying the menu data on a display screen (not shown). The MS
16
CA 02336086 2000-12-22
WO 00/01193 PCT/SE99/00925
_g_
also has a menu selector 52 for obtaining the menu selection from the
subscriber. The
MS also has a selection message generator 54 for generating the selection
message
including the menu selection, and a selection message sender 56 for sending
the
selection message to the cooperating node 30. The MS 16 further includes a
menu
storage/clearance module 58 for storing incoming menu messages and clearing
old
menu messages. The MS also includes a menu request generator 59 for issuing a
menu message thus requesting a menu. The menu selector 52, the selection
message
generator 54, the menu storage/clearance module 58 and the menu request
generator
59 may all consist, for example, of additional logic provided in the MS. The
menu
message receiver SO and the selection message sender 56 may be integrated in a
transceiver (not shown) of the MS 16, by which all messages and voice
communications are already performed.
Reference is now further made to FIGURE 3, which is a message flow diagram
illustrating the flow of messages according to a first embodiment of the
present
IS invention. In this first embodiment, the cooperating node 30 is the MSC 12,
and the
menu provided is a mufti-party call service menu. Figure 3 illustrates the
flow of
messages between the MSC 12 serving the MS 16, and that MS 16. The MSC 12
receives a MenuRequest message 60 by the menu request receiver 42. The
MenuRequest message 60 is generated upon subscriber's request by depressing a
menu button on the MS. Such a MenuRequest message 60 could also be a feature
code or any other combination of keys, which would be recognised by the MSC 12
as
meaning a request for a menu for mufti-party calling.
Alternatively, if no MenuRequest message 60 is received, the MSC 12 may
determine 62 the need for a menu by detection by the menu trigger 44 that a
menu, and
more particularly a mufti-party calling menu is required, when such a function
is
entered by the mobile subscriber. Such a need could be for example, when one
of the
two parties involved in a phone conversation establishes a communication with
a third
party. Then, the MSC 12 generates by the menu generator 32 a menu message,
hereinafter-called MenuDeliver message 64. The menu data of the MenuDeliver
message 64 includes menu items. Upon receipt at the MS 16 of the MenuDeliver
message 64 by the menu message receiver 50, a MenuReject message 66 or a
MenuAccept message 68 is generated by the MS 16 and sent to the MSC 12. The
CA 02336086 2000-12-22
WO 00/01193 PCT/SE99/00925
_9_
MenuReject message 66 and the MenuAccept message 68 may be generated by the-
selection message generator 54 and sent by the selection message sender 56, or
by any
other existing logic of the MS 16 that generates and sends acknowledgement and
refusal messages.
The MenuReject message 66 is sent to indicate that the MS is currently not
capable of receiving the identified menu. That condition may, for example,
occur
when the menu data size exceeds the data capacity of the MS, or the MS is
perforniing
some other function that does not allow the reception of the MenuDeliver
message 64
at that time. If the MS 16 is able to receive the menu, the MS sends the
MenuAccept
message 68 to the serving MSC 12. The menu items of the MenuDeliver message 64
are then displayed 70 on the display screen (as shown in Figure 4 at element
80, which
is described in greater detail below) by the menu message receiver 50. When
the
subscriber makes a menu selection 72, which is obtained by the menu selector
52, a
menu selection message, hereinafter called MenuSelection message 74 is
generated
by the selection message generator 54. The MenuSelection message 74 is sent by
the
selection message sender 56 of the MS 16, and is received by the selection
receiver 36.
The serving MSC 12 performs 76 the subscriber's selection indicated in the
received
MenuSelection message 74, using the selection performer 38. Furthermore, the
serving MSC 12 may generate and send another MenuDeliver message 78, by the
update menu generator 40 so as to update the menu on the display screen of the
MS
16.
Referring now to FIGURE 4, there is shown a block diagram illustrating the
relationship-between the MenuDeliver message 64 of FIGURE 3, menu data
displayed
on the MS display 80, and the MenuSelection message 74 of FIGURE 3 in
accordance
with the teachings of the present invention.
The MS 16 has the display screen 80, an upward button 82, a downward button
84, a send button 86, a toggle menu button 88 and a menu button 89. The upward
button 82 and the downward button 84 are used to browse through the different
items
displayed on the display screen 80. The send button 86 is used as is well
known in the
art to initiate a call, and is further used to send the MenuSelection message
74 upon
completion of menu selection by the subscriber. The menu button 89 is used to
generate from the MS 16 the MenuRequest message 60. Furthermore, it is
possible
CA 02336086 2000-12-22
WO 00/01193 PCT/SE99/00925
- I 0-
for the menu to be saved in a memory, such as the menu storage%learance module
58
of the MS 16 shown on Figure 2, and be pulled up again by the subscriber. By
allowing the storing of menus, it is possible for the MS 16 to interact with
several
menus at once. Entries made utilizing the old menu are still recognized by the
MSC
S 12, or the pertaining cooperating node, when the menu is still applicable,
i.e.
recognized by the cooperating node. For pulling back old menus, or toggling
between
menus, the toggle menu button 88 on the MS 16 is used.
By way of example, the menu items of the MenuDeliver message 64 are shown
in Figure 4. In the MenuDeliver message of the example, five menu items 90,
92, 94,
96 and 98 are presented. Each menu item is composed of four fields: a menu
item
length field, a menu item display attribute field, a menu item selection
attribute field,
and a menu item string field. The menu item length field indicates the length
of that
particular menu item. The menu item display attribute indicates the type of
displaying
that is used for the corresponding menu item string field. Examples of menu
item
display attribute are normal, blinking, reverse, hidden, etc. The menu item
selection
attribute indicates whether the corresponding menu item string field offers a
selection
to the subscriber, and what type of selection may be accepted. For example,
the menu
item selection attribute field may specify that no, or normal selection, or
default
selection, or any input which is to be hidden (not displayed on the display
screen 80)
may be accepted. Finally, the menu item string field is the information that
is to be
displayed on the display screen 80.
Turning now to the example of FIGURE 4, the first menu item 90 indicates ,
that the length of the menu item is 22 (which may correspond to a full line
for
example), that the menu item display attribute is normal, that the menu item
selection
attribute is no select, and that the menu item string is "0 to end/1 to
toggle". The
second menu item 92 indicates that the menu item length is 22, that the menu
item
display attribute is normal, that the menu item selection attribute is select,
and that the
menu item string to be displayed is "Sandra [Speech]". The third menu item 94
indicates that the menu item length is 22, that the menu item display
attribute is
normal, that the menu item selection attribute is select, and that the menu
item string
to be displayed on the display screen is "Louis [Hold]". The fourth menu item
96
indicates that the menu item length is 22, that the menu item display
attribute is
CA 02336086 2000-12-22
WO 00/01193 PCT/SE99/00925
-11-
normal, that the menu item selection attribute is select, and.that the menu
item string
to be displayed on the display screen 80 according to the mentioned display
attribute
is '2tam [Speech]". The fifth menu item 98 indicates that the menu item length
is 22,
that the menu item display attribute is normal, that the menu item selection
attribute
S is select & default, and that the menu item string to be displayed on the
display screen
80 according to the display attribute is "other". It is possible for the
subscriber
to perform a selection on the second menu item 92, the third menu item 94, the
fourth
menu item 96 and the fifth menu item 98. As shown on the display screen 80,
for
clarifying which menu items may be selected by the subscriber, a "greater
than" sign,
or other indicator, may be added in front of each menu item string which may
be the
object of a selection. Furthermore, the menu item may be highlighted,
blinking, or in
some other way made to indicate which menu item the subscriber is considering.
To
move upward in the menu, the subscriber uses the upward button 82, and to move
downward, the downward button 84. The interface displayed also includes an
"input"
line, for example, placed at the bottom of the screen, for indicating to the
subscriber
the selection made for the specified menu item string. When such a selection
is
performed and the send button 86 is pressed, the selection message generator
34 of the
MS 16 generates the MenuSelection message 74.
The MenuSelection message 74 includes the following fields: a menu type
field, a menu selection identifier field, a menu input string length field,
and a menu
input string field. The menu type field is described in greater detail below
in
conjunction with Figures 8 and 9. The menu selection identifier field
(MenuSelectionid) indicates that the selection relates to the fourth menu item
96, the
menu input string length field indicates that the length is 1, and the menu
input string
field comprises the selection performed by the subscriber, which in this
example is 1.
Because in the first embodiment the menu according to the invention relates
to mufti-party calling, the MenuDeliver message 64 carnes information on the
speech
state of currently placed calls. Possible speech states include, for example,
hold, in
speech, and in conference. The MS display screen 80 shows the calling
subscriber/called subscriber number or name, and the speech state. Also, an
indicator
for each called subscriber may be displayed for the mobile subscriber to
toggle
between the hold, speech, and conference positions. This mechanism enables
mobile
CA 02336086 2000-12-22
WO 00/01193 PCT/SE99/00925
-12-
subscribers to receive or place many calls simultaneously and to put some of
these
calls on hold while maintaining an active communication in other calls. Sub-
conferences- having only a subset of calls concurrently handled by a MS 16
active -
are also possible.
S Referring now to FIGURE 5, there is shown a message flow diagram
illustrating the flow of messages according to a second embodiment of the
invention.
In the second embodiment, the cooperating node 30 is the HLR 20, and the menu
provided to the subscriber is a transfer class menu to allow the subscriber to
perform
modifications to the services subscribed. In that second embodiment, the
subscriber
obtains a menu upon making a request for such a menu, by depressing the menu
button
89. The MenuRequest message 60 is generated by the menu request generator 59
and
sent to the HLR through the MSC 12. The MSC 12 receives the MenuRequest
message 60, determines that it is for the HLR 20 and sends the MenuRequest
message
60 to the HLR 20. In a preferred way, the MenuRequest message 60 and all other
messages exchanged between the MSC 12 and the HLR 20 are in an ANSI-41
protocol. It can be appreciated that any other protocol well known in the art
for
exchanging messages between cellular telecommunications nodes could also be
used.
The MSC 12 may also perform, if necessary, a translation between the various
menu
messages received from the MS 16 and directed to the HLR 20, or received from
the
HLR 20 and directed to the MS 16.
Alternatively, the MenuRequest message 60 can be generated by depressing
the menu button 88 shown on FIGURE 3, or by dialing a feature code, or by any
appropriate means lrnown in the art: Upon receipt of the MenuRequest message
60 in
the HhR, the latter generates a menu message through its menu generator 32 and
the
menu sender 34 sends the MenuDeliver message 64 to the MS 16 through the MSC
12. Again, upon receipt of the MenuDeliver message 64 in the MSC 12, the
latter
determines that it is addressed to the MS 16 and sends the MenuDeliver message
64
to the MS 16. Although not entirely shown, the MS generates and sends either
the
MenuReject message 66 or the MenuAccept message 68 to the HLR 20 through the
MSC 12, as previously described above in conjunction with Figure 3.
The menu message receiver of the MS 16 takes the menu items from the
MenuDeliver message 64, and displays the menu strings, as shown on FIGURE 4,
on
CA 02336086 2000-12-22
VNO 00/01193 PGT/SE99/00925
-13-
the display screen 80. Then, the subscriber makes a selection 72 and enters it
by using
the keyboard of the MS and the send button 86. The selection is detected by
the menu
selector 52, and the selection message generator generates the MenuSelection
message
74 in the same manner as shown in FIGURE 4. Upon depression of the send button
86, the MenuSelection message 74 is sent by the selection message sender 56 to
the
HLR 20 through the MSC 12. The MenuSelection message 74 is received by the
selection receiver 36, and the selection performer 38 performs the
subscriber's
selection in the HLR 20 so as to update the services of the subscriber.
Then, the update menu generator 40 of the HLR 20 generates and sends
another MenuDeliver message 78 to the MS 16 through the MSC 12. This
MenuDeliver message 78 is received by the menu message receiver 50 to update
the
information displayed on the display screen 80. If the subscriber wishes to
perform
more selections, it is possible to do so by allowing the collection and
exchange of
messages 72 to 78 be performed several times, until the subscriber selects a
menu item
called "end" (not shown), or presses a button (not shown) which is predefined
as an
"end" selection.
Reference is now made to FIGURE 6, wherein there is shown a message flow
diagram illustrating the flow of messages according to a third embodiment of
the
present invention. In that third embodiment, the cooperating node is the PSTN
node
24, and the menu provided to the subscriber is for third party services. Third
party
services are services provided by either cellular service providers or
operators other
than the cellular service provider or operator with which the subscriber has a
subscription, or services which do not relate to the cellular subscription. In
this third
embodiment, the mobile subscriber requests to obtain a menu by either pressing
the
menu button 88 shown on FIGURE 4, by dialing a special number and pressing the
send button 86 of FIGURE 4, or by using a feature code or a SMS message (not
shown) as known to those skilled in the art.
As previously explained with respect to FIGURE S, the different messages (60,
64, 68, 74, 78) are exchanged between the MS 16 and the cooperating node 30,
which
in this particular case is the PSTN node 24, by passing through the serving
MSC 12.
Furthermore, the different messages, (60, 64, 68, 74, 78) also pass through
the G-MSC
22 before reaching the PSTN node 24. For the messages exchanged between the
MSC
CA 02336086 2000-12-22
WO 00/01193 PGT/SE99/00925
-14-
12 and the G-MSC 22, the ANSI-41 protocol is prefen:ed. Of course, any other
well-
known protocol for exchanging messages between cellular telecommunications
nodes
could also be used. So, MSC 12 performs any required modifications to the menu
messages received from the MS 16 and directs them to the PSTN 24, and vice-
versa.
For its part, the gateway MSC 22 receives the various menu messages (60, 64,
68, 74
and 78) and upon determination that these are menu messages addressed to the
PSTN
24, translates the menu messages (60, 64, 68, 74 and 78) into the ISDN format
or any
other known protocol, as well known in the art, and vice-versa.
Reference is now made to FIGURE 7 which is a simplified schematic diagram
of a radio telecommunications network in accordance with a fourth embodiment
of the
present invention. That fourth embodiment combines the first, second and third
embodiments. In that fourth embodiment, different types of menus may be
obtained
by different MSs 16 at once. Each menu may be obtained, and menu selection
treated
according to previously described FIGURES 3, 5 and 6. Thus, it is possible for
MS
16(1) to obtain a menu for a mufti-party call and to perform selections as
indicated for
the first embodiment, while MS 16(2) obtains a menu for transfer class and
performs
selection for such as for the second embodiment, while MS 16(3) obtains a menu
for
a PSTN service and performs selection as described in the third embodiment.
For allowing various menu types and various nodes to be involved, a structure
for the messages exchanged between the MS 16 and the MSC 12 is described.
Reference is now made to FIGURES 8 and 9 which are, respectively, an
illustration
of the mapping of menu data in an IS-136 R-Data MenuDeliver and MenuSelection
message according to the present invention. In the preferred embodiments of
the
present invention, the cellular network 10 is a Time Division Multiple Access
(TDMA) network operating with the IS-136 air interface standard, which is
hereby
incorporated by reference herein. The invention is also applicable to other
standards
such as the Global System for Mobile Communication (GSM), the Code Division
Multiple Access (CDMA), the Digital Advanced Mobile Phone System (D-AMPS),
or the Pacific Digital Cellular Standard (PDC) or any other air interface
which has
Short Message Service (SMS) capability, or similar capabilities.
As shown on FIGURES 3, 5 and 6, four new menu messages are added to IS-
136: MenuDeliver, MenuAccept, MenuReject and MenuSelection. The present
CA 02336086 2000-12-22
WO 00/01193 PC'T/SE99/009Z5
-15-
invention sends menu messages utilizing an IS-136 R-DATA message 200 between
the cooperating node 30 (MSC 12, HLR 20 or PSTN 24 or a combination thereof)
and
the MS 16. Of course, any equivalent of the IS-136 R-DATA message may be used,
and the IS-136 R-DATA message is being used here for exemplary purposes only.
The IS-136 R-DATA message includes the following fields: a protocol
discriminator (PT) 202, a message type (MT) 204, an R-Transaction Identifier
(RTI)
206, an R-Data Unit (RDU) 208, a user destination address (LJDA) 209 and a
user
origination address (UOA) 211. As known in the art, the RDU 208 is used to
send
Short Message Service (SMS) messages (shown in broken lines). For doing so,
the
RDU 208 is divided into a Higher Layer Protocol Identifier (HLPI) 210' and a
High
Layer Protocol Data Unit (HI.,PDU) 212'. For SMS messages, HLPI 210' is set
equal
to 1. In the IS-136 standard, an HLPI 210' value of 0 indicates that the
message is
network specific, a value of 2 relates to Cellular Paging Teleservice (CPT), a
value of
3 relates to Over-The-Air Activation Teleservice (OATS), while values of 4-255
have
been set aside for future use.
One embodiment of the present invention makes use one of these reserved
values, for example, 4, to indicate that the message is a menu message
according to
the invention. The HLPI 210' is appended to the HLPDU 212' in which the SMS
data
214 is encapsulated. Thus, in that embodiment, menu messages for the HLPI 210
is
assigned the value 4 which, in turn, identifies the appended HLPDU 212 to the
MS 16
as menu data 214. The menu data 214 may be composed of several fields, which
are
used as necessary.
For example, for the MenuDeliver message 64, the fields of the menu data are:
MenuType 216, MenuId 218, MenuAddbit 220, MenuNbitem 222 and the various
Menuitems 224-228. Each of the Menuitems 224-228 are composed of four fields,
as previously described with respect to Figure 4. The MenuType 216 may take
different values, and depending of those values, the components of the menu
data 214
may vary. Some possible values of the MenuType field 216 are: Deliver,
DeliverAck
and Clear. A MenuType field 216 having value Deliver indicates that the menu
data
214 is to be delivered, while a MenuType field 216 having a value DeliverAck
indicates that the menu data 214 relates to an acknowledgement message
(MenuAccept message 68). A MenuType field 216 of value Clear indicates that
the
CA 02336086 2000-12-22
WO 00/01193 PCT/SE99/00925
-16-
display screen 80 and the menu storage/clearance module 58 of the MS 16 should
be
cleared of the indicated menu data. It is also possible to replace the
previously
mentioned MenuSelection message 74 by a MenuDeliver message 64 having a
MenuType field 216 of value equal to Selection 72.
Thus, when the MenuType field 216 is set to Deliver, the following fields in
the menu data 214 are mandatory: MenuId 218, MenuAddbit 220, MenuNbitem 222
and Menuitems 224-228. When the MenuType field 216 is set to DeliverAck, the
mandatory fields of the menu data 214 are: MenuId 218 and MenuNbitem 222. For
a MenuType field 216 of value equal to Selection, the following fields in the
menu
data 214 are mandatory: MenuId 218, MenuSelectionldentifier 230,
Menuinputstringlength 232 and Menuinputstring 234, which have previously been
discussed for Figure 4. As for the MenuType field 216 of value clear, the menu
data
214 has the MenuId field 218 as mandatory.
The MenuId 218 may be a number or an alphanumeric string identifying the
considered menu to both the serving MSC 12 and the MS 16. When several menus
are used simultaneously by the MS 16, the responsibility of the MS 16 is to
ensure that
the value of the MenuId field 218 corresponds to the appropriate menu when
sending
a MenuSelection message 74 to the cooperating node 30. In turn, the serving
MSC 12
must keep track of which menus are being used by which MS 16, even when the
MSC
12 is not the cooperating node 30 so as to avoid confusion between menus and
selection. Such a tracking is performed using the MenuId field 218.
The MenuAddbit field 220 indicates whether this menu data 214 is to be
appended to a previous menu already sent, thus allowing large menus to be sent
in
smaller chunks. The MenuNbitems field 222 informs the MS 16 as to how many
Menuitems fields 224-228 are included in the menu data 214.
As previously discussed for Figure 4, the fields of the MenuSelection message
74 are: MenuType 216, MenuId 218, MenuSelectionidentifier 230,
Menuinputstringlength 232 and Menuinputstring 234. The MenuSelectionidentifier
field 230 indicates which menu item has been selected. The
Menuinputstringlength
field 232 indicates the length of the input string, and finally the
Menuinputstring field 234 contains the string that has been entered for the
selection.
The MenuReject message 66 and the MenuAccept message 68 may be
CA 02336086 2000-12-22
W~ 00/01193 PCT/SE99/00925
-17-
composed of subsets of the previous mentioned fields of the menu data 214. For
example, the MenuReject message 66 and the MenuAccept message 68 may use the
MenuType field 216, MenuId 218 field and MenuNbitem field 222.
As known in the art, the R-DATA messages 200 are sent over the digital traffic
channel, so the menu messages may be sent simultaneously with speech. Thus,
the
MS 16 can be in the speech mode while the subscriber is receiving a menu and
toggles
through the various options in the menu and makes selections. The selections
are sent
back via the base station 14 to the MSC 12 over the digital control channel,
and if the
cooperating node 30 is not the MSC 12, the translation into the appropriate
protocol
is performed by the MSC 12. Also to allow adequate service to the mobile
subscriber,
the menu messages are sent and received in real-time, thus allowing dynamic
menu
selections and adequate service to mobile subscribers with as short delay as
possible.
While the method and system shown and described and illustrated by several
specific embodiments, the invention is not to be limited to the methods,
specific forms,
or arrangements of parts so described and illustrated. Various changes and
modifications could be made therein without departing from the spirit and
scope of the
invention as defined in the following claims. The invention is limited only by
the
claims.
