METHOD FOR REGISTERING FUNCTIONAL NUMBERS AND RELATED
DEVICES
The present invention relates to the registration of functional numbers in a mobile communication system. It is applicable in particular to GSM-Railways networks.
Wireless mobile telecommunication services are now quite commonplace. Several worldwide wireless mobile telephony standards are provided for general public use by way of subscription or similar. Wireless mobile telephony offer many advantages over standard fixed line Plain Old Telephone Services (POTS) telephony systems, the most significant being that the mobile telephone is mobile as such, provided that the use of a particular mobile telephone is made within a region covered by the operator to which a mobile subscriber is connected to.
Specialized mobile communication schemes are also becoming more frequently employed. A number of bodies are defining requirements and standards for utility mobile communication schemes for railway systems. These include the Mobile Radio for Railway Networks in Europe (MORANE) group, a consortium of European railway operators and equipment manufacturer with European Union (EU) funding who are defining a pan-European standard. The MORANE standard specifies extensions to the Global System for Mobile Communications (GSM) standard for application in the railways environment. Another project of specifying requirements or standards in this area is the European Integrated Railway Radio Enhanced Network (EIRENE), coordinated by the European Telecommunications Standards Institute (ETSI). The term GSM-Railways (GSM-R) has been adopted as an umbrella term to cover all railway system schemes. For simplicity, in the description of the present invention, reference is made to GSM-R systems and in particular to the EIRENE specification "EIRENE System Requirements Specification", Version 14, published on October 21 , 2003.
In a GSM-Railways network, communication is required between different user types such as person to person, person to system, system to system in different environments such as on the same train, from train to train, from/to ground to/from train, from ground to ground. The different types of user need to be able to communicate with each other using special railway numbers, i.e. Functional
Numbers (FN) which reflect functional information such as the train number the user is on, the function of the train such as goods or passenger, the function of the person who is assigned a particular GSM-R telephone etc. A central register, known as the Functional Home Location Register (HLRf) or Follow Me Function Node (FFN) stores the functional numbers and their related data. The intention is to enable GSM-R personnel and systems to use the functional number instead of the GSM Mobile Station ISDN (MSISDN) number for dialing and display purposes.
In order for this to work a service called "Follow Me" has been specified, which allows a Mobile Station (MS) user to register a temporarily assigned functional number against a temporarily assigned mobile station, and de-register the association once he no longer requires the functional number or the mobile station. For example when a train operator starts working on a train or in a station, he needs to be able to enter the functional number he has been assigned for the travel or for the day on the particular mobile station he is going to use, and have that association stored in a central register associated with the system. Any calls to the functional number need access to the central register to determine which mobile station the train operator is using and therefore where to route the call. The train operator needs to be able to check the status of the functional number by performing an interrogation sequence, and when the train operator has finished working with his assigned mobile station, he needs to be able to de-register the functional number. Furthermore, the follow-me feature also allows for so-called "static" functional numbers, i.e. functional numbers one cannot register or de-register, for the purpose of being able to look-up an association stored in a central register between the functional number and a mobile station id. The 3rd Generation Partnership Project has specified a Follow Me service in the technical specification 3GPP TS 23.094 v 6.0.0 entitled "Follow-Me (FM) - Stage 2 (Release 6)", published in December 2003.
Such GSM-R system includes Mobile Stations (MS) which can not only perform different types of calls, such as voice calls, data calls, but also offer the possibility to do text messaging, i.e. transmit Short Messages (SMs) between respective mobile stations.
An object of the invention is to provide an improved registration scheme for
associating a mobile station identifier with a functional number.
A more particular object of the invention is to provide an efficient registration scheme for associating a mobile station identifier with a plurality of functional numbers. According to the present invention, this object is achieved through a method for registering in a railway operator mobile network node a plurality of associations between a mobile station identifier and a plurality of functional numbers. The method comprises the step of sending, at the mobile station, a registration request message which includes a group registration operation code, and information identifying at least two functional numbers, and the step of registering, at the railway operator mobile network node, a plurality of associations each between a mobile station identifier and a functional number identified in the registration request message. This allows registration of a plurality of functional numbers with a mobile station identifier with a single registration request message. According to a preferred embodiment of the invention, the railway operator mobile network node is a Service Control Point functional node in an Intelligent Network. Preferably, the registration request message is an Unstructured Supplementary Service Data (USSD) request message which includes information identifying a first functional number in a first format, and information identifying a second functional number in a second format. In particular, the USSD registration request message may include an Operation code, a Service code, a First functional number to register, a Tag indicating a registration request for a plurality of functional numbers, a Number of functional numbers to be registered in addition to the first one, and a List of function codes. According to further preferred embodiment of the invention, the railway operator mobile network node stores the registration request format, and verifies that the information included in a received registration request is compliant to said format. The railway operator mobile network node may also send a registration outcome code to the mobile station. In some case, such registration outcome code will indicate successful registration of each association between the identifier of the mobile station and a functional number identified in the registration request message. In a partially successful registration case, the registration outcome code
- A - will indicate successful registration of a single association between the identifier of the mobile station and one of the functional numbers identified in the registration request message.
According to a further aspect of this invention, the object outlined above is achieved through a mobile station in a railway operator mobile network which comprises, in order to register a plurality of associations between its identifier and a plurality of functional numbers, means for sending to a railway operator mobile network node a registration request message which includes a group registration operation code, and information identifying at least two functional numbers. In a preferred embodiment of this further aspect of the invention, the mobile station means for sending a registration request message are adapted to send a registration request message in the form of an Unstructured Supplementary Service Data (USSD) request message. They also may be further adapted to send a registration request message which includes information identifying a first functional number in a first format, and information identifying a second functional number in a second format. Furthermore, the USSD registration request message which is sent by the mobile station may include an Operation code, a Service code, a First functional number to register, a Tag indicating a registration request for a plurality of functional numbers, a Number of functional numbers to be registered in addition to the first one, and a List of function codes.
According to yet a further aspect of this invention, the object outlined above is achieved through a service control means in a railway operator mobile network for registering a plurality of associations between a mobile station identifier and a plurality of functional numbers which comprises receiving means for receiving, from a mobile station, a registration request message which includes a group registration operation code, and information identifying at least two functional numbers, and means for registering a plurality of associations, each between an identifier of the mobile station and a functional number identified in the registration request message. In a preferred embodiment of this further aspect of the invention, the receiving means of the service control means are further adapted to receive a registration request message in the form of an Unstructured Supplementary Service
Data (USSD) request message. They also may be further adapted to receive a registration request message which includes information identifying a first functional number in a first format, and information identifying a second functional number in a second format. Furthermore, they also may be adapted to receive an USSD registration request message which includes an Operation code, a Service code, a First functional number to register, a Tag indicating a registration request for a plurality of functional numbers, a Number of functional numbers to be registered in addition to the first one, and a List of function codes.
Preferably, the service control means also comprise means for storing the registration request format, and means for verifying that the information included in a received registration request is compliant to said format. They also may comprise means for sending to the mobile station a registration outcome code. In some cases, this registration outcome code will indicate successful registration of each association between the identifier of the mobile station and a functional number identified in the registration request message. In case of a partially successful registration, this registration outcome code will indicate successful registration of a single association between the identifier of the mobile station and one of the functional numbers identified in the registration request message.
Preferably, the service control means according to the invention are included in a Service Control Point functional node in an Intelligent Network.
The present invention also proposes a method for de-registering a plurality of associations registered in a railway operator mobile network node between a mobile station identifier and a plurality of functional numbers, which comprises the steps of sending, at the mobile station, a de-registration request message which includes a group de-registration operation code, and information identifying at least two functional numbers, and de-registering, at the railway operator mobile network node, each of the plurality of associations between the mobile station identifier and a functional number identified in the de-registration request message.
The present invention also proposes a mobile station in a railway operator mobile network which comprises, in order to de-register a plurality of associations registered in a railway operator mobile network node between its identifier and a plurality of functional numbers, means for sending to the railway operator mobile
network node a de-registration request message which includes a group de- registration operation code, and information identifying at least two functional numbers.
The present invention also proposes a service control means in a railway operator mobile network for registering a plurality of associations registered between a mobile station identifier and a plurality of functional numbers which comprises receiving means for receiving, from a mobile station, a de-registration request message which includes a group de-registration operation code, and information identifying at least two functional numbers, and means for de-registering each of the plurality of associations between the mobile station identifier and a functional number identified in the de-registration request message.
The preferred features of the above aspects which are indicated by the dependent claims may be combined as appropriate, and may be combined with any of the above aspects of the invention, as would be apparent to a person skilled in the art.
The invention is illustrated hereinafter in its non-limiting application to a GSM-R system, and could also apply to other radio-communication systems.
In the preferred embodiment of the invention, a GSM-R mobile may send a USSD request for a registration or de-registration of more than one functional number to its MSISDN. The format of USSD messages are specified in the 3GPP technical specifications TS 22.090 vδ.0.0 entitled "Unstructured Supplementary Service Data (USSD) - Stage 1 (Release 6)", published in January 2005, and the technical specification TS 23.090 .Some changes to the current USSD messages for registration and deregistration of functional numbers are proposed in order to support a « bulk operation », that is to perform a registration or deregistration of a plurality of functional number within one USSD request. This bulk operation can for instance enable a lead driver to register multiple function codes within one USSD request.
In the following we describe an example of embodiment of the registration method according to the invention in a USSD request:
Bulk-Operations allow registering or deregistering of up to a predefined number of N Functional Numbers (FNs), for instance 10 FNs, with a single USSD-
Request. Lead-Drivers can initiate a Bulk Operation, in which case the Lead-FN will have the Function Code of a lead driver (for example, the Function Code 01 ). A maximum of N FNs (Lead Driver FN + N-1 FCs) can be registered or deregistered per request. In the present example, the registration and deregistration method according to the invention is embodied by using the Al ("Additional Information" field) portion of the USSD string specified for the Follow-Me service. This ensures that the used USSD string for this specific GSM-R operation is still 3GPP compliant.
The following USSD request format is proposed for a Bulk Operation request:
<OC><SC>*<LEAD_FN>***<BULK_TAG><NUM_FC><FC_LIST># with the following fields:
■ OC - FM operation code, e.g. '**' for registration;
■ SC - GSM-R FollowMe Service Code, i.e. '214'; ■ '*' - Field delimiter character;
■ <LEAD_FN> - Lead driver's FN to register/deregister, FC must be 01 ;
■ <BULK_TAG> - text tag indicating a bulk operation, this must be done to ensure/identify the special information contained on the Al portion of the USSD string, must be set to 'BULK';
■ <NUM_FC> - single digit specifying number of FCs to follow, maximum is 9;
■ FC-LIST- list of two-digit Function Codes;
■ '#' - USSD string terminator;
Example: in order to register four FNs with FC=01 , 02,03 and 04, the corresponding USSD request would be:
**214*33321234501 ***BULK3020304#
■ <OC> = '**' (registration)
- <SC> = '214'
■ <LEAD_FN> = '33321234501 '
■ <BULK_TAG> = 'BULK'
■ <NUM_FC> = '3' - <FC_LIST> = '020304'
USSD response format:
In order to prevent data inconsistencies caused by partially executed registration of multiple functional numbers, registrations or de-registrations according to a further aspect of the invention are performed in an all-or-nothing manner, i.e. either all FN-Operations or none are performed. However, should an error occur during the execution while the data is updated, no rollback of the already executed operations is done. This can cause data inconsistencies between the network and the terminal. To resolve these inconsistencies it is the responsibility of the terminal sending the Bulk Operation request to interrogate the state of each FN for synchronization purposes. This interrogation is typically done at any time in case an error is received.
The following scenarios are possible in a bulk operation:
■ Bulk Operation is successful, i.e. all FNs have been processed according to the request. A new dedicated outcome code is sent to the terminal. This ensures that the terminal is aware that all FNs have been successfully registered. The proposed outcome code is 04 for a successful bulk registration and 05 for a successful bulk deregistration. ■ Bulk Operation was invalid (i.e. the Additional Information field content was not formatted for a bulk request) and only the Lead Driver FN has been processed successfully. The outcome code for a single operation is sent to the terminal.
■ Bulk Operation has failed due to a system error. An unknown number of FNs or none have been updated successfully. It is recommended
to query all FNs to determine the current state and resynchronize the data.
■ Bulk operation has failed due to incorrect state of FN, no authorization or unknown FN. In this case the already specified outcome codes are send back and no operation have been performed
The following provides another example of embodiment of the registration method according to the invention in a USSD request:
For instance, a train MS with ■ MSISDN: +3318358777777
■ Railway Access Code: 087
■ Train Running Number: 12345
■ On Train Function Codes: 01 ; 02; 05; 99 sends a bulk registration requests to the Network Sub-System/lntelligent Network. The bulk registration request is expected to be structured as follows:
**214*08721234501 ***020599#
The complete functional number for the leading driver (e.g.: **214*08721234501) can be provided in the first part of the bulk registration requests. After the "***", in the operator specific info portion of the USSD string, the remaining On Train Function Codes can be provided (e.g.: 020599).
The modifications to the info portion of the USSD message according to the present invention include the following:
■ Add a clear identification tag to the USSD string that allows identifying the following information as part of a bulk operation. The proposed value for the tag is 'BULK'
■ Add separators between each field of the request within the info portion. The proposed value for the separator is a space.
■ As first information field of the bulk registration request add the number of function codes that should be additionally registered
which leads to the following USSD registration request message format:
**<Service Code>*<FN>***<Bulk Operation TagxNumber Of Function Codes><FO<FC>...#
With our proposed values for each of these fields the USSD message will have the following format: **214*08721234501 ***B U LK3020599#
The complete functional number for the leading driver (e.g.: **214*08721234501) may be provided in the first part of the Bulk registration requests. This is necessary should the Home Location Register (HLR) perform certain permission checks on the FN registration attempt. To ensure that those permission validations are done properly the lead driver can be checked as he usually has the most privileges.
The above-mentioned Bulk Operation Tag (<BULK_TAG>) is a text tag that identifies the info portion uniquely as a bulk registration attempt. This tag is not predefined and can be data filled on the Service Control Point. If the tag within the USSD message matches the data filled on the Service Control Point the bulk registration attempt will be handled as such.
Upon reception of a registration message with an additional info portion, the Service Control Point verifies that the info portion is compliant with the pre-defined format for bulk registrations. This means the Service Control Point checks: ■ If the Bulk Operation Tag <BULK_TAG> within the USSD message matches the data filled tag for bulk registrations on the Service Control Point;
■ If this is the case the number of function codes stored in the info portion of the USSD message is compared against the number sent in the "Number Of Functions Codes" field of the USSD request.
Additionally the Service Control Point will have a variable parameter that defines the maximum number of function codes that will be handled in a bulk registration attempt. The maximum number overall will be 10 function codes (i.e. 10 FNs). If any of the checks fails, the operation is not a bulk registration and service continues with standard single FN registration.
Once the Service Control Point has identified the USSD message as a bulk registration attempt, all requested FNs will be checked for eligibility for a registration. The bulk registration will be performed at the Service Control Point if all requested FNs are found and not registered in the SCP database. If one FN cannot be found in the SCP database or is already registered, the bulk registration attempt is rejected with the appropriate error message. This restriction to reject partial bulk registrations ensures that the mobile stations and the Service Control Point database are synchronized. For instance, in the case where one of the requested
FNs would already be registered, it would not be clear to the bulk registering mobile station who is registered to this FN.
A Bulk Registration is performed as any normal registration, i.e. the normal association between MSISDN and the functional number is done at the Service Control Point. In the described example this would be:
0872121234501 => +3318358777777 0872121234502 => +3318358777777
0872121234505 => +3318358777777
0872121234599 => +3318358777777
The expected USSD response messages are:
■ Successful bulk registration ■ Successful registration, or
■ Unsuccessful bulk registration
Successful bulk registration
A successful bulk registration will occur in case that the Service Control Point was able to set up an association between all functional numbers sent in the bulk registration message, and the MSISDN of the originating MS.
A USSD response with a new customer specific outcome code 'Successful Bulk Registration' is sent from the Service Control Point to confirm to the terminal that all FNs have been successfully registered. Besides the outcome code, this response is the same message as for a standard registration message.
The MS may assume that in case of a positive response all Functional Numbers were registered successfully in the Follow Me node.
Successful single default registration
In one embodiment of the invention which also addresses the case of a roaming user, a successful single FN registration will occur in cases where the Service Control Point in a foreign (that is, visited) network does not support the bulk registration method according to the invention. In such a case the Service Control Point performs a standard operation on the FN to register, and the USSD info string is ignored. A USSD response with the standard outcome code 01 'Successful
Registration' is sent from the Service Control Point to confirm to the terminal that the FN has been successfully registered.
This response is the same message as for a standard registration message.
The MS may distinguish between the standard and bulk operation success outcome code in a way that the registering person recognizes that the bulk operation feature is not supported in the foreign network.
Unsuccessful registration
An unsuccessful bulk registration will occur in case that the Service Control Point was unable to register one or more associations between functional numbers sent in the Bulk registration message, and the MSISDN of the originating MS. In this case the Service Control Point will do the following:
In case the problem appears before the Service Control Point registered any FN, the Service Control Point will skip registering.
In case the problem appears after the Service Control Point registered at least one FN successfully, the Service Control Point will skip registering and deregister all previously registered FNs immediately. That means the state of all affected FN will stay "unlocked and inactive" afterwards, however the MSISDN and the Timestamp are modified.
In any case the Service Control Point will send a USSD response with the outcome code of the first problem found.
Therefore one of the following problems will be reported:
■ A USSD response with outcome code 34 'System Failure' is sent to the MS in the case a service execution exception occurred on the Service Control Point. " A USSD response with outcome code 36 'Unexpected Data Value' is sent to the MS in the case the received USSD message doesn't comply with the pre-defined format for a bulk registration request.
■ A USSD response with outcome code 61 'FN already registered' is sent to the MS in the case one or more of the FNs are already registered to another MSISDN.
■ A USSD response with outcome code 41 'FN unknown' is sent to the MS in the case one or more of the FNs are unknown on the Service Control Point database. In the case where the dynamic FN feature is used this outcome code is sent if all checks for dynamic FN creation have been failing.
Further to an unsuccessful bulk registration, the terminal may try to re - register all FNs in single registration attempts.
An unsuccessful bulk registration may also occur in a roaming scenario in case the foreign Intelligent Network system does not accept the optional USSD info string at all. In this case the Intelligent Network system will send an USSD response with outcome code 36 'Unexpected Data Value'. In such a case, the intended (but not obligatory) behavior on the terminal in a roaming scenario is to prevent bulk operations.
In the following we now describe an example of embodiment of the de- registration method according to the invention in a USSD request:
The complete functional number for the leading driver (e.g.: ##214*08721234501) may be provided in the first part of the Bulk de-registration requests. After the "***" the remaining On Train Function Codes may be provided in the same format as for the registration, i.e. with the tag and the delimiter. At the time the Service Control Point is receiving a deregistration message with an additional info portion it will first of all check if the info portion is compliant to the described
format for bulk de-registrations.
This means the Service Control Point checks:
■ If the BulkOperation tag within the USSD message matches the data-filled tag for bulk " If this is the case the number of function codes stored in the info portion of the USSD message is compared against the number sent in the "Number Of Functions Codes" field of the USSD request. Additionally the Service Control Point will have a data-fillable parameter that defines the maximum number of function codes that will be handled in a bulk deregistration attempt. The maximum number overall will be 10 function codes (i.e. 10 FNs).
If any of the checks fails, the operation is not a bulk deregistration and service continues with standard single FN de-registration.
Once the Service Control Point has identified the USSD message as a bulk deregistration attempt, all requested FNs will be checked for eligibility for a deregistration. If all requested FNs are found and are registered in the SCP database, the bulk deregistration may proceed and will be performed at the Service
Control Point. If one FN cannot be found or is already deregistered, the bulk deregistration attempt will be rejected with the appropriate error message. This restriction to reject partial bulk de-registrations is required to ensure that the mobile stations and the Service Control Point database are synchronized.
The expected USSD response messages if the bulk deregistration is performed at the Service Control Point are:
■ Successful bulk de-registration ■ Successful de-registration, or
■ Unsuccessful bulk de-registration
Successful bulk de-registration
A successful bulk de-registration will occur in case that the Service Control Point was able to remove associations between all functional numbers sent in the
BuIk deregistration message, and the MSISDN of the originating MS.
A successful USSD response with customer specific outcome code 'Successful Bulk Deactivation' will be sent.
The bulk de-registration will remove associations between the originating MSISDN and the FNs listed in the de-registration USSD request. Previously registered associations between other Branches and the originating MSISDN will remain unaffected.
Successful single default de-registration
In one embodiment of the invention which also addresses the case of a roaming user, a successful single bulk de-registration will occur in cases where the Service Control Point in a foreign (that is, visited) network does not support the bulk de-registration method according to the invention. In such a case the Service Control Point performs a standard operation on the FN to de-register, and the USSD info string is ignored. A successful USSD response with outcome code 02 'Follow Me deactivated' according to the normal de-registration will be sent.
The MS may distinguish between the standard and bulk operation success outcome code in a way that the de-registering person recognizes that the bulk operation feature is not supported in the foreign network. Unsuccessful de-registration
An unsuccessful bulk de-registration will occur in case that the Service Control Point could not remove one or more associations between functional numbers sent in the Bulk de-registration message, and the MSISDN of the originating MS. In this case the Service Control Point will do the following: ■ In case the problem appears before the Service Control Point deregistered any FN, the Service Control Point will skip de- registering.
■ In case the problem appears after the Service Control Point deregistered at least one FN successfully, the Service Control Point will skip deregistering and register all previously deregistered FNs
immediately.
■ In any case the Service Control Point will send a USSD response with the outcome code of the first problem found.
Therefore one of the following problems will be reported: " An USSD response with outcome code 34 'System Failure' is sent to the MS in the case a service execution occurred on the Service Control Point.
■ A USSD response with outcome code 36 'Unexpected Data in USSD message' is sent to the MS in the case the received USSD message doesn't comply with the predefined format of a bulk de-registration request.
■ A USSD response with outcome code 63 'FN registered to another MSISDN' is sent to the MS in case one or more of the FNs are already registered to another MSISDN. " A USSD response with outcome code 41 'FN unknown' is sent to the
MS in case one or more of the FNs are unknown on the Service Control Point database.
Further to an unsuccessful bulk de-registration, the terminal may try to re- deregister all FNs in single de-registration attempts. An unsuccessful bulk de-registration may also occur in a roaming scenario in case the foreign Intelligent Network system does not accept the optional USSD info string at all. In this case the Intelligent Network system will send an USSD response with outcome code 36 'Unexpected Data Value'. In such a case, the intended (but not obligatory) behavior on the terminal in roaming scenario is to prevent bulk operations.
Some or all the steps described above could be carried out by virtue of one or several computer programs loaded and executed on computer means of the radiocommunication system.