SYSTEM AND METHOD OF PROVIDING
A MENU TO USERS OF MOBILE STATIONS
IN A RADIO TELECOMMUNICATIONS NETWORK
BACKGROUND OF THE INVENTION
Technical Field of the Tnvention 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. Description 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 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 multi-party calling service offered by the Digital Advanced Mobile Phone System (D-AMPS) and by the Global System for Mobile Communications (GSM). The multi-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 multi-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
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 multi-party call. Such inconsistencies tend to create confusion among subscribers. Thus, further 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.
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. 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 performing the menu selection. Another component of the invention is a mobile station, having 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. Upon receipt of the menu message by the mobile station, the menu data is displayed on a display screen, and a menu selection is obtained from the mobile subscriber. Then, a selection message, 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
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
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 friendly 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) 12. 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 Rl or R2) type connection. The voice trunks 11 provide voice and data communications paths used to carry subscriber communications between the MSCs 12. The signaling links 15 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 further 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 further 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,
in actual implementations it is likely that several or many BSCs are connected to an MSC 12. The voice trunk 21 A 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 21B. 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 carries 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 (PSTN) 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
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 performer 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
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 50 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 invention. In this first embodiment, the cooperating node 30 is the MSC 12, and the menu provided is a multi-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 multi-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 multi-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
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 performing 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
for the menu to be saved in a memory, such as the menu storage/clearance 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 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
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 "Nam [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 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 multi-party calling, the MenuDeliver message 64 carries 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
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. 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 known in the art. Upon receipt of the MenuRequest message 60 in the HLR, 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
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 5, 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
12 and the G-MSC 22, the ANSI-41 protocol is preferred. 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 multi-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
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 (UDA) 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 (HLPDU) 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, Menuld 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
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: Menuld 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: Menuld 218 and MenuNbitem 222. For a MenuType field 216 of value equal to Selection, the following fields in the menu data 214 are mandatory: Menuld 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 Menuld field 218 as mandatory.
The Menuld 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 Menuld 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 Menuld 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, Menuld 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
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, Menuld 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.