WO2000049825A1 - A transaction orientated data transport mechanism for use in digital cellular networks - Google Patents

Abstract

The invention provides a method and apparatus which enables data to be transferred between a service provider and user in a telecommunications network in a transaction orientated manner. A transport mechanism is described which comprises a first layer (6) suitable for interfacing with both the service provider and any other component layers (5) of the transport mechanism (30), the first layer (6) incorporating means (13, 14) for determining how data received from, and data destined for, the service provider (1) is transferred.

Description

Title

A Transaction Orientated Data Transport Mechanism for use in Digital Cellular Networks.

Technical Field

The present invention relates to wireless digital telecommunication and in particular to a system that provides narrow band data transport capability to Value Added Service Platforms ( VASP's).

Background to the Invention

Within the field of mobile digital telecommunications value added services, such as email, voice mail, unified and text messaging and other forms of data, are transferred between mobile handsets and service providers. Currently value added services are deployed over a number of transport bearers, including Short Messaging Service (SMS), Unstructured Supplementary Service Data (USSD), Circuit Switch Data (CSD), and Cellular Digit Packet Data (CDPD). Currently, the majority of deployed services use SMS especially within GSM. The traditional approach to providing (messaging) transport service is by using the Short Messaging Service Centre (SMSC) store and forward service typically provided through network based SMSC platforms.

Figure 1 shows the interaction between a value added service provider 1 and a mobile station 10 connected to a network 2 using current methodologies. The value added service provider 1 generates data that is to be transmitted to a mobile station 10 and responds to data that is received from the mobile station 10. The mobile handset or mobile station 10 is the terminal device in the mobile network 2 to which all data and voice communications for a particular subscriber in a network 2 is directed and from which all data and voice from a particular subscriber originates. A digital cellular data packet transfer mechanism 3, hereinafter referred to as a transport mechanism 3, which may comprise a short messaging entity and permanent store message switch layers 4, together with transport and relay layers 5, such as MAP and TCAP, which are both defined in accordance with known ETSI standards, is used to transfer the messages from the service provider 1 and the network 2. A layer is a set of services which are accessible via defined service points and these services are delivered by using internal functions of the layer and also using the services of other layers. Individual layers 4, 5 may communicate with each other and with the network 3 using transaction based responses, i.e. where the first layer has control over the delivery of data, but such transaction based responses are currently not transparent, or available, to the value added service provider 1.

Adequate quality of service, particularly for applications which require high message throughput and low delivery latency, for example: automatic vehicle location service (AVLS) systems, gateway products, over the air provisioning and voice mail systems, is not always possible using this method. Current SMSC technology finds it difficult to meet these requirements. High capacity and robustness can be provided by some SMSC vendors but at a very high price. In general operators are faced with the following issues when using SMSC technology for value added services:

^• High cost of ownership - the maintenance time of SMSC is very high and costly

• Robustness - Because SMSC technology is overly complex (for a data transport role) robustness is difficult to achieve at the high data rates new services demand,

• Scalability - trying to introduce new services which place high volume messaging demands on the SMSC are difficult to accurately engineer and predict.

Value added services based on SIM tool kit, Java card, HDML and TTML services and Wireless Application Protocol (WAP) are all placing new demands on the SMS transport bearer and in particular the Short Message Service Centre's (SMSC's). This is leading some operators to start looking at USSD as an alternative for more transaction based services, or trying to plan services against future technologies like GPRS. This will involve complete or partial upgrading/ replacement of hardware and software components which is expensive to implement. The new services all require the following functionality from a data bearer to provide a proper service:

• High messaging volume capability

• Low data turn around time (low latency) • Transaction like behaviour ( i.e. not store and forward but more real time behaviour)

• Guaranteed grade of service - the ability to scale the product according to demand

• Robustness

There is therefore a need for a system to address the problems associated with the provision of narrowband data transport capability to VAS platforms. Current transport market requirements include high volume messaging services and a low latency of data tranfer which is compliant with existing and emerging industry standards. These applications place less demands on the ability of the transport layers to store information and also require application side control of the data transfer. Additionally with the emergence of wireless application protocol (WAP) there is a need for WAP compliant systems.

Object of the Invention

It is an object of the invention to provide a system that overcomes the aforementioned problems and provides a fast efficient transaction based transport bearer for value added service providers.

It is a further object to provide system that is optimised to provide, high performance, with little maintenance overhead. It is a further object that such a system will be easily scaled and may be implemented in existing structures or architectures.

It is a further object to provide a system that can extend the life of Short Message Service as a value added service bearer by making it more real time, and able to meet grade of service demands as well as providing an easy way to future proof the operators investment. It is a further object to provide an interface to the system that is technology independent in that is provides access to the underlying bearer services offered by the network, for example USSD, SMS (IS41 and GSM) and in the future GPRS, which is transparent to the service provider.

It is a further object to provide a system that supports multiple technologies of bearer service using the same interface.

Summary of the Invention

Accordingly the invention provides a method of allocating a communication transport channel for the transfer of data in a digital cellular network system comprising the steps of: receiving a data transfer request, comparing a first identifier on said data transfer request to a series of stored reference values contained within at least one communication channel, comparing a second identifier on said data transfer request to a sub-series of stored reference values, determining an appropriate channel from said first comparison and allocating said data transfer request to the appropriate channel, and rejecting said data transfer request if said appropriate channel can not be determined.

The method may further include the step of transferring said data to a destination address in a manner according to a set of predefined attributes and treatments stored in said appropriate channel.

The method preferably further includes the preliminary step of making a connection comprising the steps of: obtaining a connection request from a service provider comparing an identifier of said service provider to a predefined series of stored identifiers, comparing a check parameter from said service provider to a predefined series of check parameters accepting said connection request when said identifier and said check parameter are in accordance with the stored identifier and predefined check parameter.

The method may further comprise the steps of receiving a mobile originated data request, comparing a first mobile originated identifier with a third stored reference value contained with at least one communication channel, determining if when first mobile originated identifier corresponds with the third stored reference value whether said third stored reference value is stored in a multiplicity of communication channels, comparing a second mobile originated data identifier with a fourth stored reference values contained with at least one communication channel, if the first mobile originated identifier does not corresponds with the third stored reference value, comparing a third mobile originated data identifier with a fifth stored reference contained with at least one communication channel, if the second mobile originated identifier does not corresponds with the fourth stored reference value, and rejecting said mobile originated data request if the third mobile identifier does not correspond with a fifth stored reference value, determining if the second or third mobile identifiers correspond with a fourth or fifth stored reference value respectively, being stored in a multiplicity of communication channels, cycling successive data requests to a service provider through successive respective communication channels if the second or third mobile identifiers correspond with a fourth or fifth stored reference value respectively, being stored in a multiplicity of communication channels, transmitting the data request to a service provider if the first or second or third mobile identifiers do not correspond with the third or fourth or fifth stored reference value, being stored in a multiplicity of communication channels.

The invention additionally provides a layer in a digital cellular data packet transfer mechanism for use with a digital cellular telecommunications system comprising: means for receiving a data transfer request from a service provider, means for comparing a first identifier on said data transfer request to a series of stored reference values contained within at least one communication channel , means for comparing a second identifier on said data transfer request to a sub- series of stored reference values, means for determining an appropriate channel and treatment from said first comparison and said second comparison and allocating said data transfer request to the appropriate channel.

The layer may further comprise means for configuring the data transfer request according to a set of predefined attributes and treatments stored in said appropriate channel and means for transferring said configured data to a destination address.

The layer preferably further comprises means for receiving a mobile originated data request, means for comparing a first mobile originated identifier with a third stored reference value contained with at least one communication channel, means for determining if when first mobile originated identifier corresponds with the third stored reference value whether said third stored reference value is stored in a multiplicity of communication channels, means for comparing, a second mobile originated data identifier with a fourth stored reference values contained with at least one communication channel, if the first mobile originated identifier does not corresponds with the third stored reference value, means for comparing a third mobile originated data identifier with a fifth stored reference contained with at least one communication channel, if the second mobile originated identifier does not corresponds with the fourth stored reference value, and means for rejecting said mobile originated data request if the third mobile identifier does not correspond with a fifth stored reference value, means for determining if the second or third mobile identifiers correspond with a fourth or fifth stored reference value respectively, being stored in a multiplicity of communication channels, means for cycling successive data requests to a service provider through successive respective communication channels if the second or third mobile identifiers correspond with a fourth or fifth stored reference value respectively, being stored in a multiplicity of communication channels, means for transmitting the data request to a service provider if the first or second or third mobile identifiers do not correspond with the third or fourth or fifth stored reference value, being stored in a multiplicity of communication channels.

The invention may additionally provide layer for use with a bearer network in a telecommunications system comprising: connection means for defining how external systems communicate with the bearer network, and treatment means for defining how data received from the external system is mapped onto the bearer network.

A database structure may also be provided for use in a digital cellular telecommunication system comprising: at least one channel, having one or more associated treatments whereby each channel comprises a series of definable attributes and each treatment comprises a series of definable sub-fields such that the definition of the attributes and sub-fields determines how data is transferred within the digital cellular network.

SUBSTTTUTE SHEET (RULE 26) Preferably the definition of the attributes and sub-fields within specific channels and treatments is such that the database can be used with bearer networks selected from one of more of the following: Cellular Digital Packet Data (CDPD), Global System for Mobile Communications (GSM) Short Messaging Service, GSM Unstructured Supplementary Service Data (USSD), GSM General Packet Radio Service (GPRS), iDEN (Integrated Digital Enhanced Network.) Short Messaging Service, IS-136 GUTS (General UDP Transport Service), IS-136 Short Messaging Service, Time Division Multiple Access, IS-637 Short Messaging Service, Code Division Multiple Access, or other CDMA/ TDMA bearer networks.

A transport mechanism suitable for use in a digital cellular network may additionally be provided, the mechanism comprising: transport and relay layers for transporting and relaying data on a bearer network, and further comprising the layer as described above

The invention also provides digital telecommunication system comprising: a service provider a telecommunication network a transport mechanism for transferring data between the service provider and the network whereby the transport mechanism comprises a first layer suitable for interfacing with both the service provider and any other component layer of the transport mechanism, the first layer incorporating means for determining how data received from, and data destined for, the service provider is transferred.

The first layer preferably comprises a series of channels, each channel having at least one treatment , the channels and associated treatments each comprising a set of data fields for determining how data allocated to the specific channel and treatment should be processed. The definition of the data fields related to each channel and associated treatment suitably provides an interface to the system which is independent of the underlying bearer service.

The definition of the data fields related to each channel and associated treatments suitably enables the service provider of the system to transfer data in a transaction orientated manner.

The number and definition of the attributes is preferably dependant on the application requirements and nature of the bearer technology.

The attributes may be defined with reference to one or more of the following fields: Connection Descriptor

Connection Reference

Initial State

Endpoint Address

Endpoint Type User Ack Reqd

GSM PID

Password

Connecting IP Address

Alert Required

The subfields may be defined with reference to one or more of the following fields:

Treatment ID

Input Data Type Output Data Type

GSM PID

Fragmentation Type

GSM Reply Path

MWI Service Type MWI Indication Group

Message Class The system may preferably further comprise means for operating and configuring the system including a remote operation and management interface, access to which is preferably via a system administration terminal which may be operated using remote object invocation.

The system administration terminal preferably utilises at least one graphical user interface screen.

Configuration and management of the signalling interface is preferably through the means for operating and configuring the system.

Brief Description of the Drawings

Figure 1 is a schematic of a known digital cellular telecommunications system, Figure 2 is a schematic of a digital cellular telecommunications system according to the present invention,

Figure 3 is a variant on the schematic of Figure 2,

Figure 4 shows the internal structure of an SMX layer according to the present invention

Figure 5 shows the internal structure of a channel and associated treatment, Figure 6 is a flow chart showing a connection request according to the present invention,

Figure 7 is a flow chart showing a data transfer request according to the present invention,

Figure 8 is a flow chart showing the routing of mobile originated data according to the present invention,

Figure 9 is a data flow schematic showing a data transfer request acknowledging successful transfer according to the present invention,

Figure 10 is a data flow schematic showing a data transfer request not acknowledging successful transfer according to the present invention Figure 11 is a data flow schematic showing an example of an error occurring during data transfer according to the present invention, Figure 12 is a data flow schematic showing an example of an error occurring during data transfer and a subsequent generation of alerts indicating that the error condition is no longer operable according to the present invention

Figure 13 is a flow chart showing a possible internal mechanism for the generation of alerts according to the present invention,

Figure 14 is a data flow schematic showing the transfer of two data packets according to different treatments according to the present invention,

Figure 15 is a data flow schematic showing an example of message fragmentation according to the present invention, Figure 16 is a data flow schematic showing an example of message concatenation according to the present invention,

Figure 17 is a flow chart showing a selective transmission operation according to the present invention,

Figure 18 is a schematic showing the adaptation of a single SMX layer to transfer data over a number of possible bearer networks according to the present invention,

Figure 19 is a schematic of an internal structure of an SMX layer incorporating a storage cache for storing billing related information, and

Figure 20 is a schematic illustrating the incorporation of a billing platform into a digital cellular telecommunication system having the storage cache of Figure 19

Detailed Description of the Drawings

The invention provides a mobile telecommunications system 11, shown in figure 2, suitable for an application specific interface for the delivery of data in a digital cellular mobile network. In order to provide such an interface a transport mechanism 30 is layered in a manner which separates the network and technology specific detail from the external interface, value added service provider or SMX user 1. This is achieved by replacing the short messaging entity and permanent store layers 4 associated with traditional transport mechanisms with a transport layer 6, hereinafter referred to the SMX or SMX layer. Figure 2 shows the incorporation of SMX 6 within the transport mechanism 3 illustrated in Figure 1 and described in the section background of the invention. The SMX 6 is a transport layer for the transmission of data to and from mobile handsets. The layer 6 may be driven from a higher level protocol layer such as a session layer or application layer, or directly from the VASP or SMX User 1, and communicates with these layers in a transaction orientated manner. The primary purpose of the SMX 6 is to provide a secure, reliable, error resilient, bearer independent transport layer interface for mobile data applications. The layer 6 interacts with the other components of the transport mechanism 30 and is designed as an interface that accepts variable length data from SMX User applications and transmits this data using an available bearer to a mobile station. In addition the layer may accept data from a mobile station 10 and transmit it to a SMX User 1.

The incorporation of the SMX 6, as a component of the transport mechanism 30 to enable data connections to mobile users in a mobile network, within a mobile telecommunication system 11 is illustrated in Figure 3. The same reference numerals are used for similar structures. The SMX User 1 communicates with a mobile station or handset 10 via the transport mechanism 30 and the network 2. The transport mechanism 30 comprises the existing known transport and relay layers, such as the MAP and TCAP layers 5 and also incorporates the SMX layer 6. These layers 5, 6 interact, using a physical layer appropriate to the relay layer on the bearer network, with the signalling network 2, which in the example shown in Figure 3 is an SS7 type network comprising a home location route (HLR) 7, a mobile service centre (MSC) 8 and a base station subsystem (BSS) 9. A mobile station 10, which may be a mobile phone or personal digital assistant (PDA), is connected to the network 2.

The MSC 8 is responsible for routing voice and data circuits and packets to mobile handsets 10 that are in its geographic location at a certain time, whereas the HLR 7 is responsible for the maintenance of subscriber profiles relating to subscriber location, i.e. which MSC location the subscriber is located within, and subscriber capabilities, e.g. whether a subscriber is allowed access to voice, data etc. The BSS 9 provides a management component for the radio infrastructure of the mobile network 2 and also manages the communication between switching infrastructure 7, 8 and the mobile handset 10.

The transport mechanism 30 is responsible for receiving information from the SMX User 1, determining (via a HLR 7 where necessary) to which MSC 8 the subscriber is currently attached and transmitting the data to that MSC 8. Once the data has been received by the mobile handset 10 the transport mechanism 30 will inform the SMX User 1.

In the opposite direction the transport mechanism 30 is also responsible for accepting data from a mobile handset 10 and transmitting it to the SMX User 1.

The transport mechanism 30 may be managed and configured using a system administration terminal (SAT) 12. This entity provides the human user interface to the transport mechanism for management and configuration of the SMX 6, and also for the other component layers of the mechanism 30. It incorporates an operation/ management control and monitoring interface to the transport mechanism 30.

Figure 4 shows the internal structure of the SMX 6. It comprises a series of channels 13 (Cl, C2, C3, ...CN) with associated treatments 14 ( Tl, T2, T3, ...TN). The service access point to the SMX 6 is defined as a relay layer or connection 15 which may be achieved using TCP/ IP or other networking protocols such as UDP/IP. The issues involved in the choice of relay layer are:

^• Speed ^• Reliability

^• Security

^• Quality of IP Network used to connect the SMX-User to the SMX

^• Personal Preference

The SMX 6 may also include a cache 20, which will be described later. As shown for the case of one channel in Figure 5, each channel 13 is a set of core configuration data or attributes 16 (Al, A2, A3, ...AN) which when used with the related treatment 14 is designed to cater for the requirements of a specific SMX User 1 which will use the SMX 6 for the transfer of data to a set of mobile entities. The respective treatments 14 define how data that is input to the SMX 6 from the SMX User 1 is mapped on to a bearer protocol data unit (not shown), and include a set of definable subfields 17 (SI, S2, S3, ...SN) . Typical layers 6 will contain approximately 50 such channels, each with related treatments, although this number can be changed according to specific situations and/ or applications.

Table 1 is an example of typical attributes and subfields that may be defined within a channel 13 and associated treatments 14 definition for a GSM network application. In this example the channel 13 has ten attributes ( Al, ...A10) and two associated treatments 14, each treatment has nine subfields (SI ...S9). It will be appreciated that the number and definition of the attributes and subfields will depend on the application requirements and the nature of the bearer technology to be used within the network.

Table 1

The definition of each channel attribute 13 and associated treatments 14 is stored on the SMX layer 6 . By varying the make up of each channel and associated treatments, data received by the SMX 6 will be relayed between the user 1 and the mobile station 10 in different manners.

The SMX layer 6 supports both mobile originated and mobile terminated data. Mobile terminated data transactions are defined as transactions which are initiated by an SMX-User over the transport mechanism 30, and data is transferred from the SMX-User to a mobile user in the network. The SMX User 1 must typically specify only the source information, destination information and data to be transferred. This information is used by the layer 6 to ascertain as to which channel and treatment the user 1 wished to connect to and as a result in which manner the data will be transferred.

The channels in the SMX layer 6 allow each SMX user 1 to open a connection for application specific message traffic. This connection may be dedicated to processing service primitives up to a specified pre-defined capacity level.

The connection definition is required for connection orientation of the connection between the SMX User and the SMX layer 6. Connection orientation is required to provide security services on the SMX layer and to allow the SMX layer to efficiently manage its interface to those SMX Users which are connected. Connection orientation also provides the mechanism for routing of mobile originated data to the appropriate SMX User

In order for an SMX User to open a connection and transfer data, the channel must first be defined on the SMX layer. As detailed above channel definition consists of specifying within the SMX layer, details of the SMX User that will be using the channel and details of the treatments to be available to that channel.

All data transfer transactions to the SMX 6 are performed as part of an application level session between the SMX User 1 and the SMX 6. On initiation of the application level session the layer 6 identifies the channel definition that is to be used for the lifetime of the session. Channels may be defined as having an initial state of open or an initial state of closed. Within the channel definition the following attributes relate specifically to initiation and closure of an application session:

^• Password/ connecting IP address

• Initial state.

The password and connecting IP address fields are used at initiation and termination of the session to verify that the connecting (terminating ) entity is legally allowed to perform this operation. For channels having an initial state of closed a connection initiated request, as detailed in Figure 6, must first be issued by the SMX User 1 before any subsequent data transfer requests can be dealt with.

On receipt 100 of a request to connect, the SMX layer 6 will verify 101 the IP address of the connecting party against the IP address specified in the channel definition.

If verification of the IP address is successful, the SMX layer will then verify 102 the password provided by the connecting SMX User.

If password verification is successful, the SMX layer will open the connection and send 103 an acknowledgement to the SMX User.

In the event that IP address or Password verification fails, the SMX layer will reject 103 the data transfer and respond with a negative acknowledgement to the connection request.

Once a connection has been opened, or if the channel has been defined as OPEN between the User and the layer 6, the User may initiate a data transfer request. Such a request is shown in the flow chart of Figure 7.

On receipt 105 of a request for data transfer the SMX 6 confirms 106 that a connection reference has been included in the request. Without such a reference the layer cannot allocate a channel and as such rejects 109 the data transfer request.

If the connection reference is included the layer 6 confirms 107 that a message treatment identification has been included. Without the message treatment identifier included the layer cannot allocate a specific treatment for the requested channel, and as such must reject 109 the data transfer request. With both channel and treatment identified within the SMX layer 6, the transport mechanism 30 may transfer 108 the data to the network using the attributes and subtypes of the requested channel and treatment.

In order to transmit data to a mobile user, the transport mechanism 30 must first find the MSC to which the subscriber is currently attached. In order to do this it must query the HLR for that subscriber.

However, based on the topology of the mobile network, subscribers do not typically move between MSCs very often. For this reason, the SMX layer 6 may cache the MSC address for the subscriber once it is received from the HLR, and will continue to use this MSC address until such time as it fails to reach the subscriber at that MSC. The incorporation of a caching means 20 was shown in Figure 4.

The purpose of this feature is to reduce the signalling traffic to the HLR and to improve the performance of the transport mechanism 30.

The SMX layer manages the storage required for caching location information without user intervention.

The transport mechanism 30 also supports mobile originated (MO) data. Mobile Originated (MO )data is defined as data which is received by the SMX layer 6 for onward transmission to an SMX User. Mobile originated data arrives at the SMX layer in the form of one or more Mobile Originated short messages. In order for an SMX user to receive Mobile Originated data it must first connect to the SMX layer using a previously defined channel.

Routing of Mobile originated data to a specific channel is performed based on matching the contents of the data and the addressing information provided in the SMS- MO with a channel definition. The following data items are an example of what may be used in the routing algorithm for GSM specific SMS applications. Channel :

• End Point

^• End Point type

• Protocol Identifier (PID)

Received Data as defined in known standards relating to bearer services.

^• Destination Address

^• Service Centre Address

• PID • Application specific header contained within data, e.g. WAP Headers

The routing algorithm as shown in Figure 8 operates as follows Mobile originated data is received 110

1) Match 111 Service Centre Address of received data against End Point of channels with end point type of Service Centre Address a) If multiple matches 112, match PID 113 of received data against PID of matching channels

(If there are still multiple matches 114 at this point, the SMX cycles 115 successive Mobile Originated Data transactions across the matching channels) b) If no match then continue with step 2.

2) Match 117 Destination address of received data against End Point of channels with end point type of MSISDN a) If multiple matches 114, then cycle 115 successive Mobile Originated transactions through the set of matching channels. b) If no match then continue with step 3.

3) Match PID 118 of received data with PID of channels a) If multiple matches 114, then cycle 115 successive Mobile Originated transactions through the set of matching channels. b) If no match then reject 119 ata Essentially the SMX layer 6 matches identifiers from the MO message with those in defined channels and relays the data using the predefined attributes and subtypes established- in the matching channel.

Two major error cases are handled for mobile originated data transactions. The first case is where no channel is defined to which the data can be routed. In this case the mobile originated data is rejected with an error code indicating that the destination cannot be reached by this transport mechanism. The second case is where a channel exists but is not open at the time. In this case the message is rejected but with an error code indicating that the destination is temporarily unavailable.

Incoming MO activity by a subscriber is taken as an indication that that subscriber is available to receive data. Therefore if an alert is pending for a particular subscriber, then MO data from that subscriber causes the SMX to generate the alert.

The behaviour of a connection to the SMX layer is defined by the settings associated with the connection definition being used. By altering the following channel attributes:

^• User Ack Required ^• End Point/ End Point Type/ PID,

it is possible to further refine how the data interaction between user and network will be treated by the layer. The User Ack required attribute defines in the case of mobile originated messages whether or not the mobile originated data transfer must be successfully received by the SMX User prior to being acknowledged to the client. The various end point settings instruct the layer whether to route mobile originated data to the channel in question based on the Service Centre Address/ PID combination or based on the destination address information contained in the incoming mobile originated PDU. Figure 9 shows a single SMX data transfer request with the User Acknowledgement attribute set to required in the specific channel. The flow of data is in an alphabetical ordered sequence. The SMX layer 6 receives (A) a data transfer request from the network 2 which it transfers (B) to the SMX User 1. As acknowledgement is requested the layer 6 waits, until confirmation (C) from the User 1 that the data has been received is obtained, before acknowledging (D) the original message to the network 2.

Figure 10 shows the equivalent situation where the User Acknowledgement attribute has been set to not required. As such the layer 6 acknowledges (B) receipt (A) of the mobile originated data prior to successful receipt (D) of the data from the SMX User 1.

As detailed above each channel has an associated set of treatments. Treatments may be defined which alter the behaviour of the data transfer to the MS 10 such that additional functions can be implemented. Each treatment has properties associated with it, which causes the SMX layer to treat the data transaction in a particular manner. With relation to the example highlighted in Table 1 with reference to a GSM type network, the following list defines the effect that each of the treatment flags has on the data transaction. ^• Alert Required

^• Input / Output Data Types

^• Fragmentation Type

^• PID / Reply Path / MWI Flags / Message Flags

The Alert Required setting instructs the SMX that in case of an error with a transmission using this treatment, it should generate an Alert to the SMX User on this channel when the destination in question becomes available. Alerts may not always be capable of being generated by the SMX Layer. In the case where the SMX is unable to determine a state change in an MS, or in circumstances where the error is of a permanent nature, the SMX will generate an Alert PDU with the appropriate error code contained within it. Figure 11 illustrates an example where the SMX layer 6 receives (A) data from the SMX User 1 and forwards (B) it to the Mobile Station 10 attached to the network 2. An error occurs during the data transmission, either in the network 2 or at the mobile station 10, which is related (D) back to the SMX 6. The SMX layer 6 then decides that it is unable to transmit to this Mobile Station 10 and a failure indicator is returned (E) to the SMX User 1. The data will not be stored on the SMX layer 6 once the response is sent to the SMX User 1.

Figure 12 illustrates the further example where the SMX layer 6 receives (A) the data and forwards (B) it to the Mobile Station 10. A failure occurs during the data transmission, either within the network or at the mobile station. The SMX layer 6 then decides that it is unable to transmit to this Mobile Station 10 and a failure indicator is returned (E) to the SMX User 1 as a response. The data will not be stored on the SMX layer 6 once the response is sent to the SMX User 1. If the channel has been defined to generate alerts, the SMX Layer 6 will raise (G) an alert to the SMX User 1 once the Mobile Station 10 becomes available (F). Generation of alerts may be enabled or disabled for a given connection. It is then at the discretion of the SMX User 1 to re-issue the data for that Mobile station 10.

Figure 13 shows a flow chart which outlines a possible internal mechanism for generation of alerts by the SMX layer back to the SMX User :

in the event of failure 120 Request 121 an alert from the HLR

If the resolution 122 of the error condition will not generate an alert in the HLR, Periodically PING 124 the handset for a configurable TIME PERIOD

If a PING is successful 126, then generate the alert 128 to the SMX User If an Alert is received 127 from the HLR generate 128 an Alert to the SMX User A PING operation is defined as a non-intrusive data delivery attempt to the handset. In the case of GSM, a PING is defined as a Class 0 message with no data. i.e. an empty message is sent to the handset and no record of the reception is kept by the handset.

The time period for which the PING operation is continued for, is defined as equal to the network Periodic Location Update Timer. This timer in the radio network (not shown) indicates the time period after which the mobile station must issue a location update operation to the HLR. Since an alert has been requested an alert from the HLR, this location update will cause the HLR to generate it.

Typical values for periodic location update timers vary from 30 minutes upward. The value usually depends on the coverage quality of the network, lower quality - lower value etc.

In all cases one of three things will happen,

1. one of the pings will be successful, and an alert is generated

2. the handset comes back into coverage, does a periodic location update , the HLR alerts the SMX and an alert is generated, 3. the handset has powered off and the next time it powers on it does an IMSI-attach , the HLR alerts us and we generate an alert.

The Input / Output data Sub-types define for the SMX layer how it should interpret and translate the data from an incoming PDU to an outgoing PDU. The preferred valid combinations of Input data / Output data are as follows:

^• ASCII Encoding - Binary Encoding

^• Extended ASCII Encoding - Binary Encoding

^• Binary Encoding - Binary Encoding

^• ASCII Encoding - GSM Encoding ^• Extended ASCII Encoding - GSM Encoding Table 2 illustrates an example of possible channel and treatment settings which may be used in a GSM network to alter the manner in which the data can be transferred using 7, 8 or 16 bit data.

The Channel Profile is configured as follows:

Table 2 Figure 14 shows the implementation of the specific example in the transfer of two packets of data (data packet 1, data packet 2) between the SMX User 1, the transport mechanism 30 and the Network 2. In data transfer data packet 1 the data is transferred (A) from the User 1 to the SMX layer 6 using connection reference 405 and message treatment 0. The SMX layer compares these identifiers with the channel attributes and treatment subtypes and determines that the User 1 requires 7 bit ASCII data encoding, and transfers (B) the data accordingly. On receipt (C) of acknowledgement from the network, the SMX 6 acknowledges (D) successful transmission to the User 1. In data transfer data packet 2 the user 1 specifies the same connection reference 405, but uses requests (E) treatment 2. On comparison with the channel attributes and treatment subtypes the SMX layer 6 determines that the User is requesting 8 bit binary encoding and forwards (F) the data to the network 2 accordingly. In a similar manner it acknowledges (G, H) the successful transmission to the user 1.

The Fragmentation Type setting tells the SMX 6 how it should fragment the incoming data into bearer PDUs. The SMX layer 6 supports multiple fragmentation schemes for mobile terminated data transactions. Each channel may have a fragmentation scheme defined for it. The preferred supported fragmentation schemes are as follows: ^• GSM (as defined in GSM 03.40)

^• WAP Short Binary

• WAP Long Binary

• WAP Text

By varying the settings associated with the fragmentation type it is possible to either fragment a message into a series of shorter messages, or to concatenate a series of short mobile originated messages into a single block before transmission to the SMX User. In order to cater for errors in the network etc., the SMX layer waits a configurable time between fragments before assuming that a transmission has failed. Once this time has expired the SMX layer assumes that the transmission has failed and abandons the reassembly. The data thus far received is thrown away and subsequent fragments arriving at the SMX are not accepted. Figure 15 shows an example of how a data block submitted via a data transfer request may be fragmented into multiple messages. The SMX 6 receives (A) the data block, and separates it into two separate messages. After sending (B) the first message to the network 3, the SMX waits for a response (C) from the network confirming receipt of the first message before sending (D) the second message. It is only on receiving (E) confirmation from the network that the second message has been received by the network that the SMX confirms (F) successful delivery of the data block to the SMX user 1. Figure 16 shows an equivalent situation for the concatenation of multiple mobile originated short messages into a single block before transfer to the SMX User 1. Message A is received and acknowledged to the network. Message C is then received and the two messages (A, C) are concatenated into a single message D and transferred to the User 1. In a similar fashion to that outlined with reference to Figure 15, it is only on receiving (E) confirmation from the User 1 that the message D has been received that the network is acknowledged (F).

The SMX provides resistance to transmission errors in mobile terminated data transmissions by selectively re-transmitting fragments of the data that have failed. The selective retransmission algorithm is based on the following data items which must be configured in the system ^• Maximum failures per dialog: this number indicates the total number of failures across all fragments of the data bloc that will be tolerated before abandoning the transaction, e.g. if set to 5, then a total of 5 failures on all fragments transmitted to date will cause the entire transaction to fail. ^• Maximum failures per fragment: this number indicates the number of failures on a particular fragment that will be tolerated before the entire transaction is abandoned, e.g. if set to 3, then 3 sequential failures on the same fragment will cause the entire transaction to fail. Default setting is preferably set to 3.

The algorithm then operates as shown in Figure 17. In the event that there is a failure detected 130 in the transmission 130 of a fragment the layer 6 checks to see whether either the maximum failures per dialog or maximum failures per fragment 132 has been exceeded. If these have been exceeded then the message is discarded 134. If this is not the situation the error code received is compared 133 to a list of those available for selective retry. If- it is available for selective retry then the message is sent 130 again, otherwise the message is discarded 134.

The PID, Reply Path, MWI Service Type, MWI Indication Group and Message Class fields are used to set the values of various fields in the GSM SMS Transport PDU.

Connection termination resets the connection to the inactive state. Once a connection has been terminated, it must re-established as described above before any further data transfer may take place.

The primary function of the SMX 6 within the transport mechanism 30 is to mediate the technology specifics of the mobile station interface to a consistent technology independent interface to the SMX User 1.

The SMX layer is designed to fully conform to the WAP WDP protocol. The SMX layer is specified in terms of attributes and treatments associated with specific channels. The structure of these is such that by omitting or altering certain optional parameters the form and method of the data transferred will be as required for conformance to the WAP WDP protocol. The implementation of WDP on the SMX layer is achieved by the setting of specific connection, treatment and PDU fields as follows,

1. Connection is set to OpenByDefault, no explicit connection set-up is needed. 2. Fragmentation scheme is set to WAP Short or WAP Long.

3. Data Transfer PDUs do not include a User Reference, therefore no acknowledgement will be generated.

4. Data Transfer PDUs do include Source and Destination port numbers. These will be encoded as per WDP by the SMX. 5. User Ack Required set to NotRequired, hence for MO data, the SMX will acknowledge to the handset without expecting a confirmation from the SMX-User. An example of a possible channel profile configuration is given below in Table 3:

Table 3

In a similar manner to that outlined above by simply inputting which is the required channel and treatment the SMX layer will determine how the data is to be treated.

The examples of SMX described thus far have been specific examples of the application of the SMX layer within a transport mechanism relating to a GSM specific network . By redefining channels and their respective treatments in a different manner it is possible to utilise the SMX layer as an interface to different bearer networks such as USSD, GPRS and IS41 networks. The input by the SMX user 1 will be the same for all bearer networks. On receipt of the connection reference and treatment identification the SMX layer determines which channel the User 1 is requesting, and as such how the data should be transferred. All that is required is a re-defining of the channels and treatments so as to make them compatible with the relevant networks. It will be appreciated by those skilled in the art that in certain circumstances multiple bearer networks may need to be supported. Such a situation is shown in Figure 18 where a single SMX layer 6 is used by the SMX User 1 to send data over a variety of bearer networks. By adding specific channels and related treatments to the SMX layer 6, the SMX layer becomes compatible with the various networks. The User 1 inputs a data request which, in a similar fashion to. that described with reference to the aforementioned specific GSM network, is allocated a relevant channel. This allocation or choice of channel then determines how the data is transferred to the bearer network.

Roaming / Foreign subs

The transport mechanism 30 preferably supports transmission of data to home PLMN subscribers roaming in foreign networks, as well as transmission of data to foreign subscribers roaming in the home PLMN or in foreign PLMNs.

Operations and Maintenance

The SMX layer may be configured and maintained using the system application terminal (SAT). The SAT is preferably a JAVA™ application. As the SMX layer is preferably only one layer of the many available within the transport mechanism it is preferred that the SAT may implement the configuration and operation of the SMX layer as well as other layers within the transport mechanism. The SAT is designed to be capable of being run on a separate platform from the transport mechanism 30 and is preferably written in JAVA™ so that it can be run from any JAVA™ Virtual Machine™ (VM). Alternatively, the SAT may be written in any object orientated language.

There are three main areas of functionality within the SAT: • Monitoring

• Configuration

^• Control of the Application

The monitoring area is used for the inspection of current configuration and monitoring of fault logs / event histories. The configuration area is used for the creation on new sets of configuration data and modifications to existing data.

The Application control is used for starting and stopping the application as well as activating configuration updates on the system.

Access to the SAT Functions may be protected by User Ids and user types. Users may be assigned to be either View users (with access only to Monitoring features or Super users with access to all features. Management of users is a feature only available to Super users.

The SAT breaks the user interface to the SMX in terms of the main areas within the SMX. These areas are Channels - where the application level interface to external systems is covered, Network - where the connectivity of the SMX to the SS7 network and the IP network are covered and Application - where the internal details on the SMX are covered. Within each of these areas specific items are available either for configuration or monitoring or both.

The operation of the SMX layer is determined by a set of configuration data. This data defines inter alia, the set of channels available, treatments on those channels, the SS7 network configuration etc.

In order that updates to configuration data may be performed without impact to the operation of the system, the SMX layer maintains two sets of configuration data, Primary data and Secondary data.

The SMX operates on the Primary data, while the Secondary data is worked on by operations staff. Once the Secondary configuration is ready for use by the SMX, a super user may instruct the SMX, via the SAT to switch its configuration to the Secondary data. At this point the SMX will begin operation with the Secondary data. Both the Primary and Secondary configuration data are maintained on the system at this point. Once the Super user is satisfied that the new configuration is operating correctly, the Super user may synchronise the Primary and Secondary configuration data on the system. The result of this operation is that the Primary configuration is permanently removed and a new Primary set is created from Secondary set. Prior to the synchronise, if the Super user was not satisfied with the operation of the new configuration, the SAT may be instructed to switch the configuration back from Secondary to Primary. This has the effect of restoring the previous configuration data.

During the time between switch forward and synchronise or switch back no further configuration changes may be made. Once a synchronise or a switch back have been performed, the Super user may make further changes to the Secondary data. A super user may perform a switch forward, synchronise or switch back independently of whether the system is running or not running. Independently of the switch, synchronise, switch scenario, a super user may stop and start the system at any point.

Based on the set of areas and items listed above the SAT provides a data entry interface for entry of the appropriate data. The SAT also provides a level of validity checking on the data to ensure that legal values only are entered and that any relationships between various data items are maintained.

Generally configuration operations allow for the following operations on all data

^• Add ...To add new items to the configuration

^• Delete ...To remove items from the configuration • Modify ...To alter the definition of items in the configuration

Additions, Deletions and Modifications to system configuration are effected on to the running system as described above with reference to the control of the application. Billing Module

The SMX layer may additionally be modified to incorporate a billing module. Figure 19 shows the incorporation of such a billing cache 200 into the SMX layer 6 that was previously described with reference to Figure 4. When activated, each message transaction between the mobile user and the VASP generates a toll ticket which suitably tracks or identifies the transaction between the user and VASP. These toll tickets are configurable for given channels. The format options are defined via the SAT and the channel administrator may select from a set of pre-defined fields, which are to be included in the toll ticket. Available fields include the following:

^• Toll Ticket Type

• Channel ID ^• Treatment ID

• Originating Address

^• Destination Address

• MSC Address

^• Status of Delivery ^• Error Code

^• Submission Timestamp

• Delivery Timestamp

• Message Length

• Message Priority • Message Reference

In addition the delimiter character which is used to separate fields in the billing record, such as for example a comma, may also be configured by the administration interface. This generation of toll tickets may be disabled for a channel, via the administration interface. In the case where toll ticket generation is disabled, no permanent record of the short message transaction is kept. The billing cache typically stores the information ticketed for predetermined time. If this time .is overrun the billing cache may run out of space. If this occurs the oldest data is preferably overwritten first. There is no interrogation of the billing cache, transaction details are simply transferred to the billing cache which then stores the information. Subsequent analysis of the information stored is processed after a download from the billing cache. Figure 20 shows the incorporation of a typical platform 210 which may access the billing cache over a local area network, or alternatively over a wide area network. The processing and analysis of the billing caching is done on a standard network billing system within the platform 20. Any one of a number of standard transfer protocols may be used to interrogate the billing cache. The cache is completely customisable and is preferably capable of storing data for up to 7 to 15 days. This storage capability, as will be appreciated by one skilled in the art, is dependant on the disc storage capability, and can be modified accordingly. The combination of the cache 200 and billing system 210 forms the billing module.

As discussed previously on completion of a short message transaction, the SMX layer generates a toll for the specific transaction. This toll ticket is written to the currently active ticket file. The toll ticketing subsystem (or billing system) is responsible for managing the space allocated on the system for ticket logs. The following configuration defines a typical storage of ticket logs on the system.

Based on this information the ticket (the toll ticketing subsystem) swaps over to a new log once the current log reaches the defined size or has been opened for the defined duration. The ticket manager then removes older logs upon reaching the maximum number of logs or maximum number of log entries.

Each toll ticket will indicate the event to which it relates (for example message submission, unsuccessful delivery attempt, successful delivery attempt) and will contain information relating to the source, destination, submission time, delivery time etc.. As discussed previously the system is typically defined with adequate resources to store up to 7 days worth of toll ticket logs. External systems such as Customer Administration and Billing System (CABS) may connect to the SMX layer at any point to transfer the toll ticket log stored in the billing module. The standard transfer methods supported include TCP/IP.

It is also possible to adapt the billing module for real time ticket streaming.

When this is chosen tickets are typically written to an external system using a TCP/IP socket connection. In this scenario no storage of the toll tickets is performed by the billing module cache rather the information is immediately transferred to the external procession.

Robustness

The SMX server is resilient to error conditions which may occur from time to time,

The following conditions are catered for :

1. Software Faults

In the event of a software fault occurring within the SMX application, the fault will be logged as a serious event, visible to the SAT user. If the SMX determines that it can continue operation despite this fault then it will continue. Otherwise the SMX application will reset itself and then continue operation.

2. Hardware Faults

In the event of a hardware fault, the SMX will raise an event related to the fault and if possible it will continue operation. If it cannot continue operation, it will reset itself and then attempt to continue operation.

3. Power failures

In the event of a power failure, on return of power the SMX will restart itself, restore temporary data and attempt to continue operation. 4. SS7 Network Errors

SS7 Network errors are handled as per Hardware / Software errors as described above. In addition the SMX will utilise standard SS7 techniques (alternate routing, load sharing etc.) to continue operation.

5. Platform Resource Limitations The SMX layer is designed to use only pre-defined amounts of layer resources.

However in the event that all layer resources of a particular type are used, the SMX will attempt to free resources in order to continue operation. Ultimately the SMX application will reset itself and attempt to continue operation.

6. Congestion control may be applied so as to minimise the effect of overload on the transport mechanism.

For all of the above circumstances the SAT User is informed by way of top level alarms on the SAT screen as well as specific events generated in the relevant areas of the SAT. In the case of serious platform, application or interface failures the system will trigger alarm relays to notify operations staff that there is a problem. Alarm relay triggering is configurable and may be configured via the SAT. In order to monitor the operation of the system a set of high level alarm status's are presented to all SAT users. These alarm status's are presented relating to the three major areas of the system , Channels, Network and Application. These alarm status's are presented in the form of colour coded information, red indicating a serious problem, orange indicating a less serious problem and green indicating no problem. For each of the three major areas of the system and for all appropriate sub-areas and items within the system a detailed log is maintained for all the event reports generated by the system relating to these areas / items. Again the event codes are colour coded, red indicating a serious problem, orange indicating a less serious problem and green indicating no problem.

Advantages

By using the industry standard TCP/IP LAN interface it is possible to provide access to the SMX layer in a technology independent manner that supports both IS41 and GSM. The SMX layer is Wireless Application Protocol (WAP ) compliant and by providing a WDP interface layer it is easier for Value Added Service layers to make the transition to WAP compliance. The underlying bearer of the SMX is the Short Messaging Service (SMS ) which has support over both IS41 and GSM networks, but is also upgradable to support USSD and GPRS. The incorporation of the SMX layer within a transport mechanism provides a number of advantages to the user:

^• The VAS application has full control over the data delivery ^• Dedicated access ensures a better grade of service per delivery

^• As the system is transaction based, and not reliant on store and forward, performance is improved

^• There are less nodes for the operator to manage

^• The VAS can be provided in an more cost effective manner, resulting in better margins for VAS providers

^• The integration of WDP provides a seamless access to WAP technology.

The words "comprises/comprising" and the words "having/including" when used herein with reference to the present invention are used to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Claims

Claims

1. A layer (6) in a digital cellular data packet transfer mechanism (30) for use with a digital cellular telecommunications system (11) comprising: a) means (105) for receiving a data transfer request from a service provider

(1), b) means (106) for comparing a first identifier on said data transfer request to a series of stored reference values contained within at least one communication channel, c) means (107) for comparing a second identifier on said data transfer request to a sub-series of stored reference values, d) means for determining an appropriate channel and treatment from said first comparison and said second comparison and allocating said data transfer request to the appropriate channel.

2. The layer as claimed in claim 1 further comprising: a) means (100) for obtaining a connection request from a service provider b) means (101) for comparing an identifier of said service provider to a predefined series of stored identifiers, c) means (102) for comparing a check parameter from said service provider to a predefined series of check parameters, and d) means (103) for accepting said connection request when said identifier and said check parameter are in accordance with the stored identifier and predefined check parameter.

3. The layer as claimed any preceding claim further comprising: a) means (110) for receiving a mobile originated data request from a mobile user (10), b) means (111) for comparing a first mobile originated identifier with a third stored reference value contained with at least one communication channel, c) means (112) for determining if when first mobile originated identifier corresponds with the third stored reference value whether said third stored reference value is stored in a multiplicity of communication channels, d) means (117) for comparing, a second mobile originated data identifier with a fourth stored reference values contained with at least one communication channel, if the first mobile originated identifier does not corresponds with the third stored reference value, e) means (118) for comparing a third mobile originated data identifier with a fifth stored reference contained with at least one communication channel, if the second mobile originated identifier does not corresponds with the fourth stored reference value, and means (119) for rejecting said mobile originated data request if the third mobile identifier does not correspond with a fifth stored reference value, f) means (114) for determining if the second or third mobile identifiers correspond with a fourth or fifth stored reference value respectively, being stored in a multiplicity of communication channels g) means (115) for cycling successive data requests to a service provider through successive respective communication channels if the second or third mobile identifiers correspond with a fourth or fifth stored reference value respectively, being stored in a multiplicity of communication channels, h) means (116) for transmitting the data request to a service provider if the first or second or third mobile identifiers do not correspond with the third or fourth or fifth stored reference value, being stored in a multiplicity of communication channels.

4. The layer as claimed in any preceding claim further comprising means (13) for configuring the data transfer request according to a set of predefined attributes (16) and sub-fields (17).

5. The layer as claimed in any one of claims 1 to 4 further comprising a cache means (20), said cache (20) suitable for storing the location of the mobile user 10, such that said cached location will be used for forwarding data to said mobile user until such time as said data cannot be delivered.

6. The layer as claimed in claim 5 wherein the identifiers are selected from one or more of the following; a) toll ticket type b) channel ID c) treatment ID d) originating address e) destination address f) MSC address g) status of delivery h) error code i) submission time stamp j) delivery time stamp k) message length

1) message priority m) message reference

7. The layer as claimed in any one of claims 1 to 6 further comprising a permanent transaction record storage, the storage adapted to record and store identifiers associated with the data transfer request.

8. A database structure for use in a digital cellular telecommunication system comprising: at least one channel (13), having one or more associated treatments(14) whereby each channel comprises a series of definable attributes (16) and each treatment comprises a series of definable sub-fields (17) such that the definition of the attributes and sub-fields determines how data is transferred within the digital cellular network.

9. The database structure as claimed in claim 8 whereby the definition of the attributes and sub-fields within specific channels and treatments is such that the database can be used with bearer networks selected from one of more of the following: a) Cellular Digital Packet Data (CDPD), b) Global System for Mobile Communications (GSM) Short Messaging Service, c) GSM Unstructured Supplementary Service Data (USSD), d) GSM General Packet Radio Service (GPRS), e) iDEN (Integrated Digital Enhanced Network.) Short Messaging Service, f) IS-136 GUTS (General UDP Transport Service), g) IS-136 Short Messaging Service, (Time Division Multiple Access), h) IS-637 Short Messaging Service, (Code Division Multiple Access), i) or other CDMA/ TDMA bearer networks.

10. The database structure as claimed in any one of claims 8 or 9 further comprising storage means adapted to store identifiers associated with transferred data within a digital cellular network.

11. A transport mechanism (30) suitable for use in a digital cellular network (11) comprising: a) transport and relay layers (5) for transporting and relaying data on a bearer network, and further comprising b) the layer (6) as claimed in any one of claims 1 to 7.

12. A digital telecommunication system (11) comprising: a) a service provider (1) b) a telecommunication network (2) c) a transport mechanism (30) for transferring data between the service provider and the network(2) whereby the transport mechanism comprises a first layer (6) suitable for interfacing with both the service provider and any other component layers ( 5) of the transport mechanism (30), the first layer (6) incorporating means (13, 14) for determining how data received from, and data destined for, the service provider (1) is transferred.

13. The mobile telecommunications system as claimed in claim 9 whereby the first layer (6) comprises a series of channels (13), each channel having at least one treatment (14), the channels (13) and associated treatments (14) each comprising a set of data fields for determining how data allocated to the specific channel and treatment should be processed.

14. The system as claimed in any one of claims 12 to 13 whereby the definition of the data fields related to each channel (13) and associated treatments (14) provides an interface to the system which is independent of the underlying bearer service.

15. The system as claimed in any one of claims 12 to 14 whereby the definition of the data fields (16, 17) related to each channel (13) and associated treatments

(14) enables the service provider of the system to transfer data in a transaction orientated manner.

16. The system as claimed in any one of claims 12 to 15 whereby the number and definition of the attributes (16) and subfields (17) is dependant on the application requirements and nature of the bearer technology.

17. The system as claimed in any one of claims 12 to 16 whereby the attributes may be defined with reference to one or more of the following fields: a) Connection Descriptor b) Connection Reference c) Initial State d) Endpoint Address e) Endpoint Type f) User Ack Reqd g) GSM PID h) Password i) Connecting IP Address j) Alert Required.

18. The system as claimed in any one of claims 12 to 17 whereby the subfields may be defined with reference to one or more of the following fields: a) Treatment ID b) Input Data Type c) Output Data Type d) GSM PID e) Fragmentation Type f) GSM Reply Path g) MWI Service Type h) MWI Indication Group i) Message Class

19. The system as claimed in any one of claims 9 to 18 further comprising a storage means for recording and identifiers associated with the data transfer between the service provider and the network.

20. The system is claimed in claims 9 to 19 further comprising means to interrogate the storage means, said means adapted to transfer information from the storage means to an external network processor.

21. The system as claimed in any one of claims 12 to 20 further comprising means for operating and configuring the system including a remote operation and management interface, access to which is preferably via a system administration terminal (12) which may be operated using remote object invocation.

22. A method of determining how data should be transferred between a service provider and a network in a digital cellular network system comprising the steps of : a) receiving (105) a data transfer request from a service provider b) comparing (106) a first identifier on said data transfer request to a series of stored reference values contained within at least one communication channel , c) comparing (107) a second identifier on said data transfer request to a sub- series of stored reference values, d) determining (108) an appropriate channel and treatment from said first comparison and said second comparison and allocating said data transfer request to the appropriate channel.

23. The method as claimed in claim 20 further including the preliminary step of making a connection comprising the steps of: a) obtaining (100) a connection request from a service provider b) comparing (101) an identifier of said service provider to a predefined series of stored identifiers, c) comparing (102) a check parameter from said service provider to a predefined series of check parameters d) accepting (103) said connection request when said identifier and said check parameter are in accordance with the stored identifier and predefined check parameter.

24. The method as claimed in claim 22 or 23 further comprising the steps of a) receiving (110) a mobile originated data request, b) comparing (111) a first mobile originated identifier with a third stored reference value contained with at least one communication channel, c) determining (112) if when first mobile originated identifier corresponds with the third stored reference value whether said third stored reference value is stored in a multiplicity of communication channels, d) comparing (117), a second mobile originated data identifier with a fourth stored reference values contained with at least one communication channel, if the first mobile originated identifier does not corresponds with the third stored reference value, e) comparing (118) a third mobile originated data identifier with a fifth stored reference contained with at least one communication channel, if the second mobile originated identifier does not corresponds with the fourth stored reference value, and rejecting (119) said mobile originated data request if the third mobile identifier does not correspond with a fifth stored reference value, f) determining (114) if the second or third mobile identifiers correspond with a fourth or fifth stored reference value respectively, being stored in a multiplicity of communication channels g) cycling (115) successive data requests to a service provider through successive respective communication channels if the second or third mobile identifiers correspond with a fourth or fifth stored reference value respectively, being stored in a multiplicity of communication channels, h) transmitting (116) the data request to a service provider if the first or second or third mobile identifiers do not correspond with the third or fourth or fifth stored reference value, being stored in a multiplicity of communication channels.

25. The method as claimed in any one of claims 22 to 25 further including the step of transferring (108, 115, 116) said data to a destination address in a manner according to a set of predefined attributes and treatments stored in said appropriate channel.

26. The method as claimed in any one of claims 22 to 24 further including the step of recording information associated with transfer of data between the service provider and network, and further processing said recorded information to generate a transaction history associated with said data transaction.

spec0409