EP1212627
up
EP 1212627:
METHOD AND SYSTEM FOR TRANSPORTING GENERIC DATA IN A PSTN
- Equivalents:
- AU6497100
- EC Classification:
- H04L12/58; H04Q3/00D3P
- IPC Classification:
- G01R31/08; H04J3/00; H04L5/16; H04L12/50; H04L12/28; H04M1/24
- Priority Number(s):
- US19990146510P 19990730
- Application Number:
- WO2000US20488 20000727
- Requested Patent:
- [_] EP1212627 (WO0109629)
- Applicant(s):
- TELCORDIA TECH INC (US)
- Inventor(s):
- PIETROWICZ STANLEY
- Publication date:
- 2001-02-08
- Patent Number:
- [_] WO0109629
- Invention:
- METHOD AND SYSTEM FOR TRANSPORTING GENERIC DATA IN A PSTN
Description
METHOD AND SYSTEM FOR TRANSPORTING GENERIC DATA IN A PSTN
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims the benefit of U. S. Provisional Application
No. 60/146,510, file July 30,1999, the contents of which are
incorporated herein by reference.
BACKGROUND OF THE INVENTION
1.0 Field of the Invention
My invention relates generally to transferring data from a server to a
subscriber device via the
Public Switched Telephone Network (PSTN). More particularly, my
invention relates to methods and systems for transferring data from a
server to a subscriber device via the PSTN without establishing a call
between the server and subscriber device and without the PSTN
switching components having inherent knowledge as to the data content.
2.0 Description of the Background
The rise of alternate forms of communication and the ever present need
for public safety are several trends fueling the need for a
large-scale data distribution capability that can provide timely and
efficient delivery of information to residential subscribers. With
respect to alternate forms of communication, many business subscribers
have the benefit of dedicated Internet access and typically carry a
wireless device. As a result, they have the ability to receive
timely/instantaneous notification of new awaiting email and
network-based faxes, and can be paged and receive short text messages
via wireless communications. Dedicated Internet access also allows
content providers and advertisers to push information, such as stock
quotes and targeted marketing information, to these subscribers via
emerging"push-information technologies."
However, unlike business subscribers, typical residential subscribers
do not have dedicated
Internet access and usually do not carry wireless devices. As a
result, convenient and timely methods for notifying these subscribers
of pending email and fax information or to automatically"push"new
forms of information into their homes do not exist unless these
subscribers first physically access their Internet service providers.
Similarly, Convergent Services (e. g., Unified Messaging) have emerged
that combine the capabilities of both the PSTN and Internet and
provide subscribers with a unique mix of voice and data services.
However, again, subscribers must physically access a server to
determine if there is pending information.
Public safety has also created a need for information distribution to
the residential subscriber.
Existing public alerting methods, such as community sirens that are
external to the home, are proving to be insufficient and in some cases
ineffective as the population grows and settles in new remote areas.
As a result, there is a need for public warning and emergency alerting
systems resident within the home that can alert a given population as
to the onset of severe weather or flood, the need to evacuate, a
missing child, water contamination, potential industrial hazard, etc.
Needs like those presented above can be effectively satisfied through
a data-oriented message distribution system that can send"data"from
a"central server"to a subscriber device. Such"data" could be a short
text message providing a public warning, Internet-based
advertisement/stock quotes, or a page-like message. The data could
also alert subscribers of pending information and prompt them for
information retrieval.
Although tomorrow's"Next Generation Networks"provide great flexibility
for data transport that could meet these emerging subscriber needs,
these solutions lack widespread ubiquitous deployment today. In
contrast, the current PSTN has nearly ubiquitous deployment and
continues to host a large volume of subscribers. Consequently, a
solution that could deliver data messages to subscribers based on
today's PSTN has tremendous value and potential because it would not
require the need to deploy a second data network. A conceptual diagram
of such a system is shown in Figure 1. Central server 102 aims to
deliver and exchange data/voice information with a plurality of
subscriber CPE devices, 106, through PSTN infrastructure 104.
Although the PSTN offers ubiquitous access, there are several reasons
as to why it is not an ideal network to implement data-oriented
network messaging capabilities. First, the PSTN has been traditionally
optimized to transport and switch telephone voice traffic and is
therefore characterized by fixed bandwidth, making it non-ideal for
data transport. Second, because the PSTN is designed around the
central concept of a telephone call, two endpoints cannot communicate
with one another without first establishing a switched connection.
Call connection establishment is slow and ties up switch and network
resources making the network inefficient for large-scale distribution
of data, especially for broadcast types of applications where time is
critical (e. g., as would be needed by alerting systems). In addition,
call connection establishment does not effectively meet the subscriber
needs presented above.
To be effective, the delivery of data messages needs to occur without
requiring subscriber interaction and irrespective of whether the
subscriber line is idle or in use. Ideally, a solution based on the
PSTN should only utilize the PSTN's connectivity infrastructure to
deliver data message from the central server to the subscriber-based
CPE devices.
Another issue with the PSTN is that service applications traditionally
must be deployed within the internal PSTN switching components and
require the switching components have specific knowledge of the
application in at least two ways: (1) the means by which a terminating
switch must establish a connection to a subscriber device and deliver
data to this device, and (2) the data formats used by the service
application to transport information through the network. As a result,
service applications and switching components are tied together and a
given service application cannot readilv support other types of
services without modifying the application. Hence, each time a new
service is deployed, the PSTN switching components must be
re-programmed, which is both costly and time consuming. As will be
presented below, my invention overcomes this limitation by defining a
generic framework within the PSTN infrastructure that can support
numerous services thereby severing the overriding application from the
PSTN infrastructure. As a result, service application development and
deployment are performed on the network endpoints (i. e., a central
server and CPE devices), which are less costly and time consuming to
enhance. These service applications then utilize the generic framework
of my invention without modifying the switching components.
3.0 Prior Art Systems
Prior art systems have been developed that allow a central server
(central server will be used generically in the description of the
prior art systems) to send data to a subscriber CPE device through the
PSTN. However, in addition to the concerns mentioned above related to
bandwidth limitations, callestablishment delays, and application
deployment, these systems do not address issues related to Local
Number Portability (LNP) and do not provide a cost-effective and
timely way to broadcast information to numerous subscribers. As a
result, these systems do not adequately address the emerging and
changing needs of today's residential subscriber.
In Patents 5,189,694 and 5,394,461, Stuart Garland teaches a system,
as shown in Figure 2, whereby central server 202 has a dedicated
direct"Utility Telemetry Trunk" (UTT) connections, 204208, through the
PSTN to each of a plurality of Stored Program Control Systems (SPCS)
210-214, serving desired CPE devices, 216-220. (Note that Garland
utilizes a"central office service unit"and "utility controller"that
can be collectively treated as a central server for the purposes of
this discussion.)
However, Garland's implementation posses several drawbacks with
respect to the delivery of data messages through the PSTN.
First, the system is not a true network-based solution and therefore
does not efficiently provide ubiquitous access to all subscribers.
Central server 202 requires a UTT trunk to a given SPCS before it can
communicate with the CPE served by that SPCS. Hence, the solution does
not cost effectively scale to serve all CPE in a network.
Second, to address LNP related issues, the central server requires a
UTT connection to every service provider/SPCS that may serve a given
subscriber. If there is no UTT connection, the subscriber cannot be
reached. In addition, the central server requires a database to keep
track of ported subscribers.
Third, the solution does not provide for efficient data transfer. All
communications between a central server and CPE device require a
switched voice connection be established through a UTT and the
switching matrix of a SPCS. Voice connections are time-consuming to
establish and are inherently slow for the transmission of data. In
addition, during broadcast scenarios, numerous voice connections can
create switch congestion and therefore call blocking.
Fourth, the solution does not provide a cost-effective broadcast
solution, as would be needed, for example, by an emergency alerting
application. Garland does describe a two-phase broadcast capability
whereby a central server first delivers pre-determined
broadcast-instructions (including a broadcast list of numbers) to a
SPCS. The central server then delivers to the SPCS in a second message
the data to be broadcast. However, this solution is again hindered by
the fact that large-scale broadcast requires the central server have a
UTT trunk to every switch. Another issue is that due to the speed of
the UTT trunk, it is time consuming to dynamically download new
broadcast lists, a feature that is required for delivering natural
disaster information.
Advantageously, Garland's system has a mechanism for severing an
overriding service application from the PSTN switching components, but
this mechanism has limitations. Specifically,
Garland defines a control mechanism by which the central server can
choose from one of several predefined transport services, whereby a
transport service instructs the SPCS on how to establish the
connection to the CPE and how to transport data to the CPE over the
access loop. However, because
Garland's system utilizes a"GR-30-CORE"interface (as defined in
GR-30-CORE LSSGR Voiceband
Data Transmission Interface, Section 6.6, by Telcordia Technologies,
Inc.) between the SPCS and CPE, each transport service has a
predefined data format for transmission. Hence, the transport services
are inherently based on certain types of service applications and as a
result, there is an inherent limitation as to the types of
applications that can be implemented on this system without the
continuous definition of new transport services. New transport
services require re-programming of the PSTN switching components.
Nortel Networks, Inc. describes in functional feature document,
Suppressed Ringing Access, a system for establishing a suppressed
ringing access call connection between a central server and a
subscriber device through the use of a modified version of Integrated
Services Digital Network (ISDN) call setup (ISDN and CCS/SS7 call
establishment do not support signaling for suppressed ringing access).
Under this system, a central server places a call to a service
activating directory number/application on the terminating SPCS that
serves the subscriber. The SPCS-based application then completes the
suppressed ringing access connection to the subscriber. Because the
system utilizes
ISDN call setup procedures, there is no need for dedicated trunks, as
is the case with Garland, thereby making the system ubiquitous and
scalable (i. e., the call connection is switched through the network).
However, the system still poses several drawbacks making it non-ideal
for data message transport.
First, similar to Garland, the transmission of data between the
central server and CPE device utilizes a switch-based voice
connection. This connection is time consuming to establish, especially
when having to make numerous connections such as for broadcast
applications.
Second, the system has LNP related issues for ported subscribers
because the central server places the call to a switched-based
application on the SPCS rather than directly to the subscriber. Hence,
the call establishment procedures do not inherently resolve the
subscriber's number and re-route the call.
To solve this LNP issue, the SPCS would need to maintain a local
database of ported numbers, which is costly.
Third, the application is inherently tied to the PSTN switching
components and therefore lacks flexibility to support other
applications. Unlike Garland, the system does not define a control
mechanism between the central server and terminating SPCS whereby the
server can instruct the SPCS on how to establish the connection to the
CPE device. Call establishment procedures are hardcoded in the SPCS
based application.
Lastly, the system only supports subscriber broadcast by sending
individual messages to each subscriber, which is inefficient.
Telcordia Technologies, Inc. defined a message waiting notification
service in, TR-NWT-1401:
LSSGR Visual Message Waiting Indicator, and GR-866-CORE : ISDN Message
Service Generic
Switching and Signaling Requirements, as shown in Figure 3. Under this
service, network-based voicemail system 302 (the central server for
the purposes of this discussion) records voice messages for a
subscriber. System 302 then notifies the subscriber that new voice
messages are waiting by activating an indicator on subscriber CPE
device 316 as follows. Voicemail system 302 sends a message,
describing the subscriber's incoming call history, to originating SPCS
306 over access link 304, which is either an ISDN/Message Desk
Interface (MDI) or a Simplified Message Desk Interface (SMDI).
Originating SPCS 306 in turn notifies terminating SPCS 312 of the call
history by launching a "Transaction Capabilities Application Part"
(TCAP) query over CCS network 308. SPCS 312 then notifies CPE device
316 of the call history by sending a message over access link 314
using either a GR30-CORE predefined message or through ISDN non-call
associated signaling.
Because this solution utilizes the CCS/SS7 network, it advantageously
supports the delivery of data from a central server to a subscriber
without the need to establish a voice connection. It also addresses
ported numbers. However, this system has several drawbacks making it
non-ideal for data message transport.
First, the solution is tailored towards a specific application
(voicemail notification) and is therefore not adaptable to
applications requiring other forms of message transfer. Specifically,
the protocols defined for transporting data from the voicemail system
to the originating SPCS, between the originating and terminating
SPCS's, and from the terminating SPCS to the CPE device are specific
to the transport of voicemail information and are not adaptable to the
transport of any data (i. e., the data content is limited in both size
and type). In addition, the system does not define a mechanism for the
central server to instruct the terminating SPCS on how to establish
the connection from the terminating
SPCS to the CPE device. Both issues prevent the system from supporting
service applications other than voicemail without modification to the
PSTN switching components.
Second, the solution does not support a broadcast mechanism from the
central server to a plurality of subscribers. The central server could
broadcast a message, one-at-a-time to numerous subscribers, but this
is time-consuming and could potentially create congestion within the
CCS/SS7 network.
Telcordia Technologies, Inc. also defined an AIN function, called
the"Create-Call"function, in GR-1298-CORE: AINGR : Switching Systems.
This function permits a Service Control Point (SCP) to request that a
switch establish a call on behalf of a subscriber CPE device.
Specifically, through this function the SCP can instruct a switch to
first alert a CPE device and then establish a call to a central server
(e. g., an Intelligent Peripheral) from this device. Unlike the
systems described above, here the call is originated from the
subscriber rather than from the central server. One application of
this function is to setup an unattended call between an Intelligent
Peripheral and an ADSI screen-phone to download service scripts.
The Create-Call function poses several drawbacks making it non-ideal
for data message transport. First, the function does not support
efficient broadcast from a central server since call origination
occurs from the CPE device to the central server. Second, the function
does not provide for efficient data transfer since all communications
between a central server and CPE device require a switched voice
connection. Third, the function is limited with respect to the types
of data that can be sent to a CPE device.
SUMMARY OF THE INVENTION
It is desirable to have a method and apparatus for efficiently
exchanging data-oriented messages from a service application residing
on a central server to subscriber CPE devices over the PSTN network
that overcome the above and other disadvantages of the prior art.
Methods consistent with my invention deliver service application data
from a central server to a subscriber device by means of the PSTN
network. It is an objective of my invention that this data delivery be
generic such that only the central server and subscriber device have
inherent knowledge of the application data. The PSTN infrastructure,
consisting of an originating SPCS serving the central server, a
terminating SPCS serving the subscriber device, and a signaling
network interconnecting the originating and terminating SPCS's, have
no embedded knowledge of the application data and simply treat the
data as generic. As a result of my invention, new service applications
are severed from the PSTN infrastructure in that these services can be
deployed between a central server and CPE device without modifying the
internal PSTN infrastructure.
Specifically, under my invention, the central server accepts data from
a service application and defines a generic request message, which
contains the service application data and data delivery instructions
that instruct the terminating SPCS on how to deliver the service
application data to the subscriber device. The central server
addresses the request message to the subscriber, based on the
subscriber's PSTN address, and transports the message to a"Generic
Data Message Transport" (GDMT) application residing on the originating
SPCS via a non-call associated ISDN interface or SMDI interface. The
originating SPCS then encapsulates the request message in a typical
TCAP message and transports the TCAP message to a Signaling Transfer
Point (STP). In another embodiment of my invention, the central server
has a CCS/SS7 interface and directly interfaces with the STP,
bypassing the originating SPCS.
Regardless of whether the central server interfaces with the
originating SPCS or STP, the STP resolves the subscriber's address for
LNP related issues and subsequently routes the TCAP message to a
GDMT application residing on the terminating SPCS. Upon receiving the
TCAP message, the terminating SPCS extracts the application data and
data delivery instructions from the generic request message and
transports the application data as a generic data block to the
subscriber device based on the data delivery instructions. Throughout
the data transport, the application data is never examined by the
PSTN infrastructure.
Optionally, the central server can instruct the terminating SPCS via
the request message to report on the delivery status of the
application data to the subscriber device. In this case, the
terminating
SPCS defines a response message, which contains the delivery status
data, and transports this message through the STP back to the central
server directly or through the originating SPCS.
In another embodiment of my invention, the central server broadcasts
the service application data to multiple subscribers. In this
embodiment, the central server continues to define a generic request
message containing application data and data delivery instructions.
Within the data delivery instructions is a list of subscriber PSTN
addresses served by the terminating SPCS that are to receive the
application data. The request message is addressed with one of these
subscriber addresses and is transported to the
STP as above. The STP resolves LNP related issues based on the single
subscriber address and subsequently routes the message to the
terminating SPCS. The terminating SPCS then delivers the application
data as a generic data block to each subscriber device specified in
the delivery instructions.
Because the STP only resolves a single address from the list of
subscriber addresses, it is possible that one or more of the
subscriber devices specified in the subscriber list are no longer
served by the terminating SPCS. As a result, the terminating SPCS
defines a response message for the central server specifying each
subscriber device that did not receive the application data. The
central server subsequently defines and delivers for each specified
subscriber a request message containing the application data.
My invention has several advantages over the prior art. First, the
central server has ubiquitous access to all subscriber devices within
the PSTN. Second, data delivery does not require a call be established
between the central server and subscriber devices and does not utilize
the PSTN/SPCS switching fabric. As a result, switch congestion is
avoided and the speed of data delivery is increased.
Third, my invention provides an efficient method and means for the
central server to broadcast data to multiple subscribers throughout
the PSTN. Forth, my invention accounts for number portability issues.
Another significant advantage of my invention over the prior art is
that my invention focuses on an effective and efficient means by which
the overriding service application data is"generic"to the
PSTN switching components. Specifically, the PSTN switching components
do not require embedded knowledge of the service application data
being transported or how that data should be delivered to the
subscriber device. The central server performs all data formatting
based on the over-riding service application (a function typically
performed by the terminating SPCS) and transports this data along with
data delivery instructions to the terminating SPCS, which blindly
passes the data to the subscriber device based on the delivery
instructions. As a result, new service applications can be deployed
completely on the central server and subscriber devices. These
applications simply use the methods and apparatus of my invention as a
framework infrastructure to communicate between the central server and
subscriber devices. This arrangement significantly reduces the cost
and time to deploy new services.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a conceptual diagram of transporting data from a central
server to a plurality of subscriber devices via the PSTN.
Figure 2 is a block diagram illustrating a prior art system by Stuart
Garland, Patents 5,189,694 and 5,394, 461.
Figure 3 is a block diagram illustrating a prior art voicemail system
by Telcordia Technologies,
Inc.
Figure 4 is a block diagram illustrating the different segments of the
network through which generic data is transported from the central
server to the subscriber devices.
Figure 5 is a block diagram illustrating a system suitable for
execution of methods consistent with the present invention.
Figure 6 is a block diagram illustrating the"Generic Data Message
Format"for the GR-30
CORE interface.
Figure 7 is a block diagram illustrating a specific application in
accordance with the present invention.
DETAILED DESCRIPTION OF THE INVENTION 1.0 Overview
Reference will now be made in detail to the preferred embodiment of my
invention. Turning to
Figure 4, there is depicted a PSTN architecture on which my invention
is implemented. The system consists of a plurality of subscribers with
CPE devices, such as devices 418-420, central server 402, and PSTN 408
for providing interconnection between the central server and the
subscriber devices.
PSTN 408 consists further of originating SPCS 406 serving central
server 402, terminating SPCS 416 serving subscriber devices 418-420,
STP's 404 and 414, transport network 412 supporting communications
between subscribers, and CCS/SS7 signaling network 410. Central server
402 contains service application 460 intended to provide"data message
services"to subscriber devices 418-422.
The objective of my invention is to provide a generic transport
mechanism, hereinafter referred to as the
Generic Data Message Transport (GDMT) capability, from central server
402 to subscriber devices 418 -422 through which service applications,
such as service application 460, can transport data messages to the
subscriber devices. Specifically, it is an objective of my invention
to define methods and apparatus for the transport of data from central
server 402 to subscriber devices 418-422 through the
PSTN such that originating SPCS 406, terminating SPCS 416, STP's 404
and 414, CCS/SS7 network 410, and transport network 412 have no
inherent knowledge of service application 460 or the data being
transported. As such, my invention provides a generic framework on
which any data message delivery applications can be deployed without
modifying the PSTN infrastructure. It is a further objective of my
invention that the data delivery occur without establishing a switched
based call connection between central server 402 and CPE devices
418-422 and that the data delivery occur without subscriber
interaction.
Hereinafter, the focus of this application is on the transport
of"generic"data message from the central server to the CPE devices.
The GDMT system can be broken into three transport segments for
discussion purposes.
Segment 430 provides for generic data message delivery between central
server 402 and PSTN 408.
Central Server 402 accesses PSTN 408 either through originating SPCS
406 (through an ISDN or SMDI interface 442), or through STP 404
(through CCS/SS7 interface 440). Segment 434 provides for generic data
message delivery between terminating SPCS 416 and subscriber CPE
devices 418-422. Access over this segment is either through an analog
interface, an ISDN interface, or a Digital Subscriber Loop (DSL)
interface. Segment 432 provides for generic data message delivery
between originating SPCS 406/STP 404 and terminating SPCS 416.
Delivery over this segment is via the CCS/SS7 network.
Figure 5 shows a detailed diagram of one specific illustrative
embodiment of the GDMT system.
As an example, central server 402 wishes to send a generic data
message, containing data generated by service application 460, to CPE
device 418. Central server 402 formulates a generic message request
consisting of both the service application data for subscriber 418 and
delivery information, which instructs terminating SPCS 416 on how to
deliver this message to subscriber 418. Central server 402 addresses
the generic message for subscriber 418 using telephony based
addressing and transfers this message to GDMT subsystem 506 on
originating SPCS 406 over either ISDN or SMDI interface 442.
Assuming subscriber 418 is not served by originating SPCS 406, GDMT
subsystem 506 extracts the generic data message request (both the
message and delivery instructions) from the data interface and
transfers the request over the CCS/SS7 network to STP 508. Similarly,
if central server 402 has
CCS/SS7 capabilities, the central server can transfer the generic
message request directly to STP 508 over CCS/SS7 interface 440. STP
508 resolves LNP related addressing issues through LNP database 514
and then routes the generic data message to GDMT subsystem 512 on
terminating SPCS 416.
GDMT Subsystem 512 extracts the delivery instructions and the service
application data for subscriber 418 from the generic data message
request. Subsequently, GDMT Subsystem 512 delivers the data to
subscriber 418 based on the delivery instructions. Upon delivery, GDMT
Subsystem 512 formulates a generic response message and conveys this
message back to central server 402 through the network thereby
informing the central server on the status of the delivery.
The following discussion will first cover the structure of the generic
data message that is transferred between central server 402 and
subscriber devices 418-422. The discussion will then specifically
describe the method of transport of this generic data message over
each transport segment.
2.0 Description of Generic Data Message Structure
One objective of the GDMT system is for the central server to define a
generic data message and deliver this message to the subscriber
without requiring intervening nodes within the network, such as the
terminating SPCS, to have specific knowledge of the data message. As
is further described below, once the generic data message is delivered
to the terminating S the generic data message to the subscriber. Table
2 contains the"data type definitions"for each of the parameters of the
DeliveryControlInfo structure as defined in Table 1.
Table 1: ASN. 1 Representation of the Generic Data Message Delivery
Request
Structure Definition Parameter Data Type Parameter Definition
GenericDataMessageDeliveryRequest:: =
SEQUENCE
genericDataMessage [0] IMPLICIT Contains the service
GenericDataMessage application data to be
delivered from the central
server to the CPE device (s)
deliveryControllnfo [1] IMPLICIT Contains information
DeliveryControllnfo instructing the terminating
SPCS on how to delivery the
generic data to the CPE
device.
}
GenericDataMessage:: = Choice (
octetMessage [0] IMPLICIT OCTET
STRING
bitMessage [1] IMPLICIT BIT
STRING
}
Sequence{DeliveryControllnfo::=
Contains a numeric ID
IMPLICITINTEGERassignedbythecentralservertransactionID[0]
and used to link the request
and response messages
Table 1 (continued): ASN. 1 Representation of the Generic Data Message
Delivery Request
Structure Definition Parameter Data Type Parameter Definition
callin Number [1] IMPLICIT OCTET Contains the directory number
assigned to the central server
STRING(OPTIONAL) interface. This element is
(OPTIONAL).
Contains the time date when
timestamp [2] IMPLICIT OCTET the central server launched the
STRING(OPTIONAL) delivery request. This element is
(OPTIONAL).
identifierContainsan for the
mSRID [3]IMPLICIT OCTET
central server or a subsystem in
STRING(OPTIONAL) the central server that launched
the generic data message
request. This data element is
(OPTIONAL). If provided, it shall
be used by the terminating SPCS
in the response message.
bearerCapability [4] IMPLICIT OCTET Describes the type of bearer
STRING (OPTIONAL) service needed, if any. This
element is (OPTIONAL).
pilotDN [5] IMPLICIT OCTET Contains a 10-digit directory
STRING number of one subscriber that will
receive the generic data message.
The pilotDN is used for routing
and LNP determination.
Describes three methods for
[6]IMPLICIT specifying the directory numbers
thesubscriberswhowillreceiveBroadcastTypeof
(OPTIONAL) thegeneric data message for
broadcast. The first method
indicates a list of one or more
specified directory numbers. The
second method indicates a range
of directory numbers within a
NPA-NXX. The third method
indicates an entire NPA-NXX
available on a SPCS without
specific mention of every directory
number. This element is
(OPTIONAL). If not included in the
message, delivery to the single
destination indicated by the
pilotDN is assumed.
Specifies the inclusive start and
stop range of directory numbers
BroadcastRange that will receive the generic data
(OPTIONAL) message when the broadcastType
is set to range. This element is
(OPTIONAL).
dNList [8] IMPLICIT DNList Contains one or more directory
(OPT ONAL) numbers that will receive the
generic data message when the
broadcastType is a single or
specified list of directory numbers.
This element is (OPTIONAL).
Table 1 (continued): ASN. 1 Representation of the Generic Data Message
Delivery Request
Structure Definition Parameter Data Type Parameter Definition
Specifies the number of times a
terminating SPCS shall re
attempt to deliver the generic
data message to a subscriber
before reporting a delivery
failure.
Specifies the type of access line
subscriberLineType ispermittedthat to receive the
datamessage.ThisSubscriberLineTypegeneric
(OPTIONAL) element is (OPTIONAL)
deliveryMode Specifies whether the terminating
SPCS shall attempt to deliver the
generic data message in the on
hook, off-hook or both states. For
ISDN access lines, the on-hook
state means no calls are in
progress (i. e., no call associated
call references).
SpecifiesSpecifiesthe frame format and
transmissionFormattransmissionFormat[12]IMPLICIT formatandthe frame
TransmissionFormat physical layer that the
(OPTIONAL) terminating SPCS should apply
when delivering the generic data
message.
Specifies whether the terminating
SPCS should frame bytes within
the generic data message before
delivery.
onHookAlertingSignalType [14]IMPLICIT Specifies the type of alerting
Signal the terminating SPCS
beforeshouldapply transmitting
(OPTIONAL) the generic data message in the
on-hook state. This element
defines a set of alerting signals.
One or more alerting signals may
be selected. The order in which
they are encoded dictates the
order of application. This allows
numerous alerting combinations.
This element is (OPTIONAL). If
no alerting signal type structure
is present, no alerting is to be
applied during generic data
message delivery.
Table 1 (continued): ASN. 1 Representation of the Generic Data Message
Delivery Request
Structure Definition Parameter Data Type Parameter Definition
Specifies the type of alerting
AlertingSignalType signal t terminating SPCS
(OPTIONAL) should apply before transmitting
the generic data message in the
off-hook state. This element
defines a set of alerting signals.
One or more alerting signals may
be selected. The order in which
they are encoded dictates the
order of application. This allows
numerous alerting combinations.
This element is (OPTIONAL). If
no alerting signal type structure
is present, no alerting is to be
applied during generic data
message delivery.
requireAlertingACK [16] IMPLICIT Specifies whether the terminating
DecisionYesNo SPCS requires a CPE
acknowledgment of the alerting
signal before sending the generic
data message.
Specifies whether the terminating
DecisionYesNo SPCS should report the detection
(OPTIONAL) of a CPE acknowledgment of the
alerting signal to the central
server. This element is only
needed if a CPE
acknowledgment of the alerting
signal is required.
dialToneType [18] IMPLICIT Specifies the dial tone type the
dialToneType (OPTIONAL) terminating SPCS should provide
the subscriber upon going off
hook. This element is
(OPTIONAL).
Specifies whether the terminating
DecisionYesNo SPCS requires an
acknowledgment of the generic
data message by the CPE.
reportMessageACK [20] IMPLICIT Specifies whether the terminating
DecisionYesNo SPCS reports the detection of a
(OPTIONAL) CPE acknowledgment of the
generic data message. This
element is only needed if a CPE
acknowledgment of the generic
data message is required.
[21] IMPLICIT Specifies how the SPCS should
forwardingControl ForwardingControl handle delivery when
encountering AIN triggers or
features such as forwarding or
terminating screening associated
with a destination directory
number.
)
Table 2: ASN. 1 Generic Data Message Delivery Request Data Element
Descriptions
Structure Definition Parameter Data Type Parameter Definition
BroadcastType:: = ENUMERATED See Table 1.
ListofDnslistOfDNs(0)
RangeofDNsrangeOfDNs(1)
AllallDN/s(2) DNs within a NPA-NXX
)
SeeTable 1.
BroadcastRange::=SEQUENCE
{
directorynumberinaThelower
IMPLICITOCTETSTRINGdirectorynumberdNRangeStart[0] range for
message broadcast application.
The upper directory number in a
directory number range for
message broadcast application.
All directory numbers in between
the start and stop directory num
bers, inclusive, receive the
generic data message.
DNList:: = SET See Table 1.
dN [0] IMPLICIT OCTET STRING
additionalDNs [1] IMPLICIT SET OF DNList
(OPTIONAL)
}
See Table 1.
SubscriberLineType::=
ENUMERATED
analog (0)
ISDN (1)
both (2)
AllTypes(3)
}
1.SeeTable
DeliveryMode:: = ENUMERATED
onHookOnly (0)
offHookOnly (1)
both 2
}
Table 2 (continued): ASN. 1 Generic Data Message Delivery Request Data
Element Descriptions
Structure Definition Parameter Data Type Parameter Definition
See Table 1.
Transmission Format:: =
ENUMERATED
1200 baud GR-30-CORE
gr30GDMF (0) Generic Data Message Format.
1200 baud GR-30-CORE
gr30GDMFWoCS (1) Generic Data Message Format
without Channel Seizure Signal.
1200 baud GR-30-CORE
gr30GDMFWoCSMS (2) Generic Data Message Format
without Channel Seizure Signal
and Mark Signal.
2400 baud GR-30-CORE
gr30GDMF2400 (3) Generic Data Message Format.
2400 baud GR-30-CORE
gr30GDMFWoCS2400 (4) Generic Data Message Format
without Channel Seizure Signal.
2400 baud GR-30-CORE
gr30GDMFWoCSMS240 (5) Generic Data Message Format
0 without Channel Seizure Signal
and Mark Signal.
ISDN D Channel Layer 3
iSDNDChannel (6) NOTIFY message encapsulation.
Transmission format using DSL
packets.dSLpacket(7)
Reserved Message Format.
reservedFormatl 8
See Table 1.
ByteFraming ::= ENUMERATED
{
Frame each byte a
precedingstartbit(space)andstartStopByteFraming(0)
ending stop bit (mark).
Do not frame the data. Simply
noFraming (1) encapsulate it into the data
frame.
See Table 1.
AlertingSignalType : : = SET
(Note: Signals get applied in the
order in which they are coded)
none [0] IMPLICIT INTEGER No alerting signal.
(OPTIONAL)
thedurationINTEGERspecifies
openSwitchlnterval [1]IMPLICIT INTEGER of line orinterruption
(OPTIONAL) removal of battery in ms
(nominally 150 to 350 ms).
Table 2 (continued): ASN. 1 Generic Data Message Delivery Request Data
Element Descriptions
Structure Definition Parameter Data Parameter Definition
thedurationINTEGERspecifies
INTEGERofbatteryreversalinmslineReversal[2]IMPLICIT
150(OPTIONAL)(nominally to 350 ms).
pingRing [3]IMPLICIT INTEGER INTEGER specifies the duration
of Power Ringing Burst in ms.
(OPTIONAL)
AAringing pattern defined by
OtherRingTypeOtherRingType.otherRingType[4]IMPLICT
(OPTIONAL)
INTEGER specifies the duration
subscriberAlertingSignal ofa440HzburstinmsINTEGER
(OPTIONAL) (nominally 300 ms).
A signal
OtherSASTypedefinedbyOtherSASType.otherSASType[6]IMPLICIT
(OPTIONAL)
[7] IMPLICIT INTEGER INTEGER specifies the duration
cPEAlertingSignal (OPTIONAL) of a 2130 Hz & 2750 Hz burst in
ms; (nominally 80 ms, extended
250 ms).
[8] IMPLICIT OtherSignaIType An alerting signal defined by
otherSignalType (OPTIONAL) OtherSignalType.
OtherRingType:: = ENUMERATED
{
Power Ringing Cadence: 500 ms
on,250msoff,500mson,250specialRingPattern(0)
special off, 1000 ms on, 250
ms off, 1000 ms on.
Cadence:500PowerRinging ms
on,250msdistinctiveRingPattern(1) off,1000 ms on, 250
ms off, 500 ms on.
Power Ringing Cadence: 800 ms
codedRingPattern (2) on, 400 ms off, 800 ms on.
OtherSASType:: = ENUMERATED
{
100 ms on, 100 ms off, 250 ms
distinctiveSAS1 (0) on, 100 ms off, 100 ms on of 440
Hz.
100 ms on, 100 ms off, 100 ms
distinctiveSAS2 (1) on, 100 ms off, 250 ms on of 440
Hz.
}
OtherSignalType::=
ENUMERATED
Reserved
voicebandSignall(0)
Reserved
voicebandSignal2 (1)
Table 2 (continued): ASN. 1 Generic Data Message Delivery Request Data
Element Descriptions
Structure Definition Parameter Data Type Parameter Definition
Reserved
voicebandSignal3(2)
}
SeeTable 1.
DecisionYesNo:: =
ENUMERATED
{
no (0
es 1
See Table 1.
DialToneType:: = ENUMERATED
Continuous application of 350 Hz
steadyDialTone (0) & 440 Hz.
messageWaitingDialTon (1) 10 times followed by continuous
application of 350 Hz & 440 Hz.
100 ms on, 100 ms off repeated
recallDialTone (2) 3 times followed by continuous
application of 350 Hz & 440 Hz.
See Table 1.
ForwardingControl ::= SET
{
Defined by ForwardCase.
IMPLICITcontrolType[0] ForwardCase
[1] IMPLICIT SET OF Defined by ForwardCase.
moreControlTypes ForwardingControl
(OPTIONAL)
}
See Table 1.
ForwardCase:: = ENUMERATED
Deliver generic data message to
noForwarding (0) specified directory number and
disregard all forwarding and
artificial make-busy features.
Allow forwarding features to
allowForwarding (1) redirect delivery of generic data
messages.
Disregard any AIN triggers and
deliver generic data message to
specified directory number.
Disregard any terminating
disregardTerminatingScr (3) screening features and deliver
eening generic data message to
specified directory number.
The second structure, GenericDataMessageDeliveryResponse, is a
delivery response structure sent by the terminating SPCS to the
central server and is defined as shown in Table 3. This structure is
also defined in ASN. 1 format. Looking at the fields of the
message,"transactionID"is identical to the "transactionID"field in the
GenericDataMessageDeliveryRequest structure and links the response to
a request."mSRID"is identical to the"mSRID"field in the
GenericDataMessageDeliveryRequest structure and identifies the central
server, or subsystem within the central server, that initiated the
generic data message. "response"indicates, through
the"Response"structure, the delivery success or failure of the data
message to a subscriber (s)-specifically-"resultType"indicates,
through the ResultType structure, the success or failure of delivery
and the corresponding subscriber (s) are identified either through
the"dNList,""broadcastRange"or"broadcastType"elements. Multiple sets
of the
Response structure can be combined into a single
GenericDataMessageDeliveryResponse message thereby acknowledging
multiple request messages. Table 4 provides a detailed description for
each element of the ResultType structure.
Table 3: ASN. 1 Representation of the Generic Data Message Delivery
Response
Structure Definition Parameter Data Type Parameter Definition
GenericDataMessageDeliveryResponse:: =
SEQUENCE
transactionl D [0] I MPLICIT INTEGER
mSRID [1] IMPLICIT OCTET STRING
(OPTIONAL)
[2] MPL) C) T Response
response
}
Response:: = SEQUENCE
resultType [0 IMPLICIT ResuItType
dNList [11 IMPLICIT DNList (OPTIONAL)
broadcastRange [2] IMPLICIT BroadcastRange See Table 2 for
(OPTIONAL) BroadcastRange definition.
broadcastType [3] IMPLICIT BroadcastType See Table 2 for
(OPTIONAL) BroadcastType definition.
more [4] IMPLICIT SET OF Response
(OPTIONAL)
J
Table 4: ASN. 1 Representation of the ResultType Structure
Structure Definition Parameter Data Type Parameter Definition
ResuItType:: = ENUMERATED {
The generic data message has been
successfulDeliveryOnHook (0) successfully delivered to the
directory numbers indicated in the
dNList, broadcastRange or all
numbers in the NPA-NXX (if the
broadcastType is alIDNs in the off
hook mode).
The generic data message has been
successfulDeliveryOffHook (1) successfully delivered to the
directory numbers indicated in the
dNList, broadcastRange or all
numbers in the NPA-NXX (if the
broadcastType is a ! ! DNs in the off
hook mode).
The alerting signal, if specified in the
delivery request message, was
acknowledged by the directory
numbers indicated in the dNList,
broadcastRange or all numbers in
the NPA-NXX (if the broadcastType
is alIDNs).
The message ACK, if required as
messageACKReceived (3) specified in the delivery request
message, was received from the
directory numbers indicated in the
dNList, broadcastRange or all
numbers in the NPA-NXX (if the
broadcastType is a ! ! DNs).
A directory number in the dNList has
dNOutsideNPANXX (4) a NPA-NXX that is different from the
pilotDN.
The directory numbers in the dNList
portedNumber (5) or broadcastRange have been
ported.
The directory numbers in the dNList
failureToDeliverRetriesExceeded (6) or broadcastRange have not been
delivered in the requested number
of attempts.
The directory numbers indicated in
generalDeliveryFailure (7) the dNList, broadcastRange or all
numbers in the NPA-NXX (if the
broadcastType is allDNs) have not
received the generic data
Table 4 (continued): ASN. 1 Representation of the ResultType Structure
Structure Definition Parameter Data Type Parameter Definition
accessLineNotAllowed The directory numbers in the dNList
or broadcastRange have a line type
that does not match the line type
permitted in the delivery request
message.
The transmission format specified is
not supporte for the subscriber line
interface
An An error exists in the request
message (12) message (i. e., a critical parameter is
missing)
3.0 Transport Segment Descriptions
Thus far, the generic structure of the data message to be transferred
between central server 402 and CPE devices 418-422 has been described.
In general, central server 402 defines the
GenericDataMessageDeliveryRequest structure containing both the
generic data message\service application data (genericDataMessage) and
instructions telling the terminating SPCS how to deliver this message
to the CPE device (s) (deliveryControlInfo). Central server 402
transfers the
GenericDataMessageDeliveryRequest structure over transport segment 430
to originating SPCS 406 and
GDMT subsystem 506. GDMT subsystem 506 then transfers the structure
over transport segment 432 to terminating SPCS 416 and GDMT subsystem
512. GDMT subsystem 512 extracts the genericDataMessage and
deliveryControlInfo structures and sends the genericDataMessage
structure over segment 434 to CPE device (s) 418-422 using the
delivery instructions specified in the deliveryControlInfo structure.
Based on the status of the delivery to the CPE devices, GDMT subsystem
512 then creates a GenericDataMessageDeliveryResponse structure
containing the delivery status and returns this structure to central
server 402.
Reference will now be made, in accordance with my invention, to how
the request and response structures are transferred over each
transport segment starting with segment 434 (subscriber access), then
segment 430 (central server access), and lastly segment 432 (network
transport segment).
3.1 Subscriber Access
As indicated earlier, the access interface between subscribers 418-422
and terminating SPCS 416 is either analog, ISDN, or DSL access. The
method for analog and ISDN access will be described below. Because DSL
interfaces contain both analog interface support and out of band
packet communications support similar to ISDN, the methods described
for analog and ISDN interfaces can readily apply to DSL interfaces. In
addition to the analog and ISDN access description, a description of
how the central server instructs the terminating SPCS as to which
subscriber (s) are to receive the generic data message is provided.
Analog Access Interface
GR-30-CORE defines a data transmission method for analog access lines
between a SPCS and a subscriber. The GR-30-CORE interface currently
supports, for example, CLASSSM services such as
Caller Identity Delivery, Calling Identity Delivery on Call Waiting,
and Visual Message Waiting
Indicator. Although it uses the voice-frequency-band between the
subscriber and SPCS, a central feature of the GR-30-CORE interface is
that it does not require the establishment of a call nor does it use
the
SPCS core-voice-switching-fabric.
The GR-30-CORE interface defines data formats and CPE data delivery
options to which an over-riding service application on a terminating
SPCS must conform. As a result, these data formats and delivery
options must be embedded in the service application thereby making the
application tied to a specific purpose and requiring service
application development within the SPCS. This is the case with prior
art systems like"Visual Message Waiting Indicator. "Again, an
objective of the GDMT system is to sever the over-riding service
application from the terminating SPCS. A description of how my
invention severs the GR-30-CORE data formats and delivery options from
the overriding service application are now discussed, beginning with
the data formats and then the delivery options.
The GR-30-CORE interface currently defines two data formats, Single
Data Message Format (SDMF) and Multiple Data Message Format (MDMF),
which must be used by the over-riding service application. The issue
with these two"formats"is that they require a given service
application to specifically format subscriber data according to that
application. As a result, service application development must take
place within the SPCS. Again, SPCS feature development has proven
costly and time-consuming thereby affecting new feature rollout.
An objective of the GDMT system is for the terminating SPCS to
relinquish control of the overriding service application and allow the
central server to define the message as necessary and simply utilize
the generic transport capabilities of the PSTN and terminating SPCS.
In this respect, a new message format, called the"Generic Data Message
Format" (GDMF), is defined for the GR-30-CORE interface as is
illustrated in Figure 6.
Unlike the SDMF and MDMF formats, the GDMF format allows for the
transport of data by the terminating SPCS to the subscriber CPE device
without requiring the terminating SPCS have specific knowledge of that
data (Under the SDMF and MDMF formats, the terminating SPCS is
required to format the subscriber data based on the specific
application.). The GDMF format delivers a generic message in data
payload 606 without requiring the terminating SPCS to perform
segmentation or processing of the information, without requiring the
SPCS to map different pieces of application data into specific
parameters, and without requiring the SPCS to generate a checksum for
error detection. The terminating SPCS is only required to perform a
transport function; in other words, insert the generic data message
received from the central server into data payload 606 of the GDMF
envelope and transmit the frame to the CPE device using the physical
layer defined in GR-30-CORE. Hence, under the current invention, GDMT
subsystem 512 on terminating SPCS 416 extracts the genericDataMessage
structure sent by the central server in the
GenericDataMessageDeliveryRequest message and inserts it directly into
data payload 606 of the GDMF envelope.
The GDMF format therefore allows the GR-30-CORE interface to transmit
a data message completely defined by a central server. The advantage
of this flexibility is that new services that require data delivery to
analog access devices can be quickly introduced/deployed because they
do not require a special SPCS application first be developed. Once a
SPCS supports the GDMF feature and GDMT subsystem, this single feature
can serve the needs of many new services. Furthermore, the GDMF format
is cost effective because it uses the same physical layer as the SDMF
and MDMF formats and thereby does not require hardware modifications
to the SPCS.
Turning to the current GR-30-CORE delivery options, like the SDMF and
MDMF data formats, the delivery options are currently hard-coded
within the SPCS based service application. Under the current
invention, rather than define only a single delivery option within
GDMT subsystem 512, the central server defines the delivery options
through the deliveryControlInfo structure and delivers these options
to GDMT subsystem 512 along with the generic data message through the
GenericDataMessageDeliveryRequest structure. GDMT subsystem 512
extracts the deliveryControlInfo structure and uses it to determine
how the generic data message should be delivered to the subscriber.
For example:
* Through the"deliveryMode"parameter, the central server can instruct
GDMT subsystem
512 to attempt to deliver the message only if the subscriber is in the
on-hook state, only if
the subscriber is in the off-hook state, or regardless of the state.
* Depending on the state of the subscriber (on-hook, off-hook), the
central server can specify
to GDMT subsystem 512 the type of alerting signal to use through the
"onHookAlteringSignalType"and"offHookSignalType"parameters. For
example, in the
on-hook case, the generic data message may be preceded by no alert,
one of several ringing
patterns, an Open Switching Interval (OSI), a battery reversal, a
voiceband tone signal, etc.
In the off-hook case, the SPCS must circumvent the call in progress.
Here, the SPCS will
break into the call, mute the far end party, and then apply an
off-hook alerting signal
consisting of no alert, Subscriber Alerting Signal (SAS) and a CPE
Alerting Signal (CAS),
voiceband tone signal, etc.
* Through the"transmissionFormat"parameter, the central server can
specify whether GDMT
subsystem 512 should transmit the GDMF envelope with Channel Seizure
Signal 602 and/or
Mark Signal 604. These preamble signals are placed under the control
of the central server
because in service applications where delivery time is critical, such
as broadcast
applications, these two signals can take significant time to transmit.
Through
the"requireAlertingACK","reportAlertingACK","requireMessageACK",
"reportMessageACK"parameters, the central server can instruct GDMT
subsystem 512 to
require the subscriber CPE to acknowledge receipt of the alerting
signals and the generic
data message, and then report the success or failure of the receipts
back to the central server
through the GenericDataMessageDeliveryResponse structure.
ISDNAccess Interface
With respect to subscribers served by ISDN interfaces, delivering the
generic data message is comparatively simpler than the method
described above for subscribers served by analog access lines.
The key difference is that the ISDN interface already supports
out-of-band signaling via the D channel, which is used to pass all
call control messages between the terminating SPCS and an ISDN
terminal.
Under my invention, when the central server delivers the
GenericDataMessageDeliveryRequest structure to the terminating SPCS,
the SPCS directly embeds the genericDataMessage structure and the
deliveryControlInfo data into a Q. 931 NOTIFY Message and as a result,
like the GR-30-CORE interface, does not require the SPCS have specific
knowledge of the data. The SPCS then delivers the NOTIFY Message using
Non-Call Associated Signaling (NCAS), which allows the message to be
sent at any time regardless of the state (on-hook, off-hook) of the
interface.
Table 5 illustrates one method of encoding a Q. 931 ISDN NOTIFY
message containing the generic data message. This ISDN message is
constructed as a call independent message using the NULL
Call Reference Value. The key components include the Notification
Indicator Information Element, the
Signal Information Element, the Calling Party Number Information
Element, and the Called Party
Number Information Element. The genericDataMessage structure is placed
directly in the"ASN. 1
Encoded Data Structure"field of the Notification Indicator Information
Element, again requiring no modification by the SPCS, and the
Notification Description field is set to 03H (Extension to ASN. l
Encoded Component). The Signal information element is defined by
mapping the alerting signal parameters (onHookAlertingSignalType and
offHookAlertingSignalType) from the deliveryControlInfo structure, as
describe above. The Calling Party Number Information Element is
likewise populated based on the CallingNumber element from the
deliveryControlInfo structure or, as an alternative, provided by the
SPCS directly.
Table 5: ISDN NOTIFY Message Coding
Data Element Value
ProtocolDiscriminator Q. 931
Call Reference Value Null ("0000 0000")-Non-call Associated
Signaling
Message Type NOTIFY
"0000 0100"Identifier
Bearer Capability Information Element
Bearer Capability Call Independent Signaling Connection
"0010 0111"Identifier
Notification Indicator Information Element
"0000 0011"-Extension to ASN. 1 Encoded
Notification Description Component
ASN. 1 Encoded Data Structure GenericDataMessage Structure (See Table
je
"0011 0100"Identifier
Signal Information Element AlertSignalType's mapped from the
Signal Value DeliveryControllnfo Structure (see Table 2)
"0110 1100"Identifier
Calling Party Number Information Element Calling Number provided
either by the SPCS
Number or the Central Server in the
DeliveryControlinfo Structure (see Table 1)
"0111 0000"Identifier
Called Party Number Information Element DN Provided by the Central
Server
Number
Note that regardless of whether the access interface is analog or
ISDN, terminating SPCS 416 will need to determine if any"vertical
services"are active on the subscriber line and route the generic data
message based on the instructions in the"ForwardingControl"structure
in the deliveryControlInfo structure. In addition, once the delivery
(or attempted delivery) of the message to the subscriber (s) is
complete, terminating SPCS 416 will formulate, if indicated by the
deliveryControlInfo structure, a delivery status response via the
GenericDataMessageDeliveryResponse structure and return this message
to the central server via the CCS/SS7 network, which is further
described below.
Designatinv a Subscriber
Before proceeding, it is beneficial to describe how the central server
instructs GDMT Subsystem 512 on the terminating SPCS as to which
subscriber (s) are to receive the message. As described thus far, the
GDMT system supports delivery of generic data messages from the
central server to a single subscriber. In this case, the central
server specifies the target subscriber to the terminating SPCS through
the"pilotDN"parameter of the deliveryControlInfo structure. However,
in addition to supporting delivery of generic data messages to a
single subscriber, another objective of my invention is to support
broadcast capabilities from the central server to multiple subscribers
(e. g., for emergency altering applications). Rather than the central
server sending an individual message to every subscriber, as would be
the case under the prior art systems, the central server sends one
message to each terminating SPCS that serves subscribers that are to
be reached along with a designation of these subscribers. Each
terminating SPCS then forwards the message to the designated
subscribers. The central server specifies the target subscribers to
the SPCS in one of three ways through the deliveryControlInfo
structure, as designated below.
1. All Directory Numbers within a List: Under this method, a list of
directory numbers are
specified in the"dNList"structure, specifying to the terminating SPCS
as to which subscribers
should receive the message.
2. All Directory Numbers within a Range: Under this method, a range of
directory numbers is
specified by a start and stop directory number in
the"broadcastRange"structure.
3. All directory numbers within a single NPA-NXX: Under this method,
an indicator is set to
convey to the terminating SPCS that the generic data message is to be
delivered to all directory
numbers within a single NPA-NXX available on the SPCS.
Because broadcast occurs from the perspective of the terminating SPCS,
the central server should first group the directory numbers according
to a NPA-NXX so that a SPCS does not receive a delivery request for a
subscriber it does not inherently serve.
3.2 Central Server Access
Central server 402 is responsible for creating, on behalf of the
overriding service application, the
GenericDataMessageDeliveryRequest structure consisting of the generic
data message\service application data (i. e., genericDataMessage) and
the instructions telling GDMT Subsystem 512 on terminating SPCS 416
how to deliver this message to the subscriber (i. e.,
deliveryControlInfo). Central server 402 transmits this message either
to GDMT Subsystem 506 on originating SPCS 406 over data interface 442
(for subsequent delivery to the CCS network through STP 508), or
directly to STP 508 over CCS/SS7 interface 440, if the central server
has CCS/SS7 capabilities. Correspondingly, these interfaces are used
to deliver the GenericDataMessageDeliveryResponse structure generated
by GDMT
Subsystem 512 on terminating SPCS 416 back to central server 402.
In accordance with my invention, the generic data messages are
transferred over interface 442 between originating SPCS 406 and
central server 402 either through an SMDI or ISDN interface. The next
section describes how the GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures are transferred over
these interfaces. The following section discusses how these structures
are transferred over CCS/SS7 interface 440.
Simplified Message Desk Access Interface (SMDI)
SMDI is an analog data interface that uses an asynchronous serial
transmission protocol to transfer 7 bit ASCII data. Because the
GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures are binary based
structures, the SMDI 7 bit ASCII protocol presents several challenges
for transferring data. Consequently, a special transfer syntax (i. e.,
encoding rules) is needed to communicate the request and response
messages between central server 402 and originating SPCS 406. The
central server encodes the GenericDataMessageDeliveryRequest structure
as follows:
"REQ: GDMT" Number-of Diits Number-of-Elements Set-of-Elements" <
Control D > "
* REQ : GDMT is an operation and format tag, respectively, that
indicates to the
originating SPCS that the central server is wishing to invoke GDMT
subsystem 506.
As indicated in Table 1, the GenericDataMessageDeliveryRequest
structure is an
ASN. 1 sequence of elements consisting of
an"octetMessage"or"bitMessage", and
a"transactionID","callingNumber","timestamp", etc. Set-of-Elements is
a list of
these elements for the current message, the encoding of which is
discussed below.
Number-of-Elements is the number of elements in the list
Set-of-Elements. Number-
of-Elements represents this number as a string of ASCII digits (1
through 9).
Number-of-Di is a single ASCII digit (1 through 9) indicating the
number of
ASCII characters in the Number-of-Elements string.
* As indicated, Set-of-Elements represents the sequence of elements,
from both the
genericDataMessage structure and the deliveryControlInfo structure,
that constitutes
the GenericDataMessageDeliveryRequest structure. Not all elements
defined by the
GenericDataMessageDeliveryRequest structure need to appear in the
command
sequence for every request since several of the elements are
(OPTIONAL). The
order of the elements in this field is arbitrary.
'" < Contro ! D > "signifies end-of-transmission to the originating
SPCS.
Similarly, the GenericDataMessageDeliveryResponse structure sent from
the originating SPCS to the central server is encoded as follows: "
GDMT"Number-of-Di its Number-of-Elements transactionlD mSRID
Set-of-Elements" "
"GDMT"indicates to central server 402 that the originating SPCS is
sending a
GenericDataMessageDeliveryResponse structure (i. e., sending back a
response from
an earlier request).
* As indicated in Table 3, the GenericDataMessageDeliveryResponse
structure is an
ASN. 1 sequence of elements consisting of a"transactionID","mSRID",
and
"response"wherein"response"represents a sequence of elements through
the
"Response"structure (i. e.,"resultType","DnList","broadcastRange", and
"broadcastType"). Set-of-Elements represents the sequence of elements
from the
"Response"structure. As indicated earlier,
multiple"Response"structures can be
combined in the same GenericDataMessageDeliveryResponse, provided that
each
"Response"is reporting a status related to the
same"transactionID"and"mSRID".
As a result, the Set-of-Elements sequence consists of one or more sets
of
"Response"structures wherein a set is the"resultType"element and
either a
"dNList","broadcastRange"or"broadcastType"element. The order of the
elements
in the sequence is always"resultType"first.
transactionlD represents the"transactionID"element of the
GenericDataMessageDeliveryResponse structure.
* mSRID represents the"mSRID"element of the
GenericDataMessageDeliveryResponse structure.
* Number-of-Elements is the number of elements in the list
Set-of-Elements. Number-
of Elements represents this number as a string of ASCII digits (1
through 9).
Number-of-Digits is a single ASCII digit (1 through 9) indicating the
number of
ASCII characters in the Number-of-Elements string.
'" < LFxControl D > "signifies end-of-transmission to the central
server.
Each of the elements, represented by Set-of-Elements above, that
comprises the
GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures can be classified as
either a structure (includes: genericDataMessage, bearerCapability,
onHookAlertingSignalType, and, offHookAlertingSignalType) or as a
single parameter (all other elements, e. g., pilotDN, boadcastType,
resultType, etc.). Structures can be further classified as an octet
string/binary data or as a set-of-parameters. Accordingly, structures
are encoded in one of two formats (format 1 for octet strings and
format 2 for set-of-parameters):
1. Stag Number-of-Digits Bvte-Lenth-Value ASCII-Encoded-Binary-Data
2. Stag Number-of Number-of-Parameters Set-of-Parameters
ta" represents a two key character that identifies the structure type
(e. g.,
genericDataMessage:"GM", offHookSignalType:"NA").
ASCll-Encoded-Binarv-Data represents the octet string/binary data. The
octet
string must be re-formatted as 7 bit ASCII data in order to conform to
the SMDI
interface. Specifically, the transmitting application converts each
8-bit binary data
byte into two 7-bit ASCII characters by splitting each 8-bit binary
data byte into two
4-bit segments called"trailing nibbles."A leading nibble ("011") is
pre-pended to
each trailing nibble to create a 7 bit ASCII byte in the range of 30H
to 3FH,
representing ASCII'0'through' ?'. The receiving application decodes
the data by
discarding the leading nibble on each ASCII byte and combining every
two trailing
nibbles to reassemble the 8 bit binary byte.
# Byte-Length-Value represents the number of ASCII characters in the
ASCII Encoded-Binarv-Data field. Number-of is a single ASCII digit (1
through 9)
indicating the number of ASCII digits needed to represent the
Byte-Length-Value.
# Set-of-Parameters represents the set of parameters constituting a
structure with
multiple parameters. The encoding of parameters is described below.
# Number-of-Parameters is the number of parameters in the set
Set-of-Parameters.
Number-of-Digits is a single ASCII digit (1 through 9) indicating the
number of
ASCII characters in the Number-of-Parameters string.
In both structures, it should be noted that the originating SPCS can
parse the data by counting bytes or counting parameters and never
needs to interpret the content of the message, thereby maintaining the
objective of severing the overriding service application from the
network infrastructure.
Parameters, whether represented as a single element or as a member of
a structure, are encoded in one of two formats:
1. Ptag value
2. PtaQ valueI" & "value2" & "... value""t"
Ptag represents a two-character key that identifies the parameter
type.
value, valuel, value2, and value"contain one or more ASCII bytes
representing the
parameter value.
& is a delimiter of values when a parameter supports a list of values
(e. g., dNList).
*/ils a delimiter when there are multiple parameters (e. g.,
onHookAlertingSignalType).
The encoding for structures and parameters for the
GenericDataMessageDeliveryRequest structure and
GenericDataMessageDeliveryResponse structure are shown in Table 6 and
Table 7.
Table 6: Structure Encodings for the GenericDataMessageDeliveryRequest
and
GenericDataMessageDeliveryResponse Structures
Structure Stag Binary Data or Parameter Encodings
genericDataMessage"GM"ASCII encoded binary data representing the Data
Message.
bearerCapabilty"BC"ASCII encoded binary data representing the Bearer
Capability.
onHookAlteringSignalType"NA". openSwitchlnterval:"OS ddd !"
ddd: 3 ASCII digits representing the duration of the
open switching interval between 000 and 999 ms.
# lineReversal :"LR eeee!"
* eue: 3 ASCII digits representing the duration of the
line reversal between 000 and 999 ms.
# ffff""PR
# ffff : 4 ASCII digits representing the duration of the
ping ring burst between 0000 and 9999
Table 7: Parameter Encodings for the GenericDataMessageDeliveryRequest
and
GenericDataMessageDeliveryResponse Structures
Parameter Ptag Parameter Encoding
#"TDxxxx!"transactionID"TD"
xxxx: 4 ASCII Digits from'0'to'9'representing the
RequestID
callingNumber"CN"."CN xxxxxxxxxx!"
xxxxxxxxxx: 10 ASCII Digits from'0'to'9'
representing the Calling Number.
#"TSYYYYMMDDhhmm!"timeStamp"TS"
YYYYMMDDhhmm: 12 ASCII Digits from'0'to'9'
wherein YYYYMMDDhhmm represents the year,
month, day, hour, and minute, respectively.
#"IDxxx!"mSRID"ID"
# xxx : 3 ASCII Digits from'0'to'9'representing the
central server or subsystem identifier.
pilotDN"PD"."PD xxxxxxxxxx!"
# xxxxxxxxxx : 10 ASCII Digits from'0'to'9'
representing the Pilot DN.
#listOfDNs:"BT'0'!"broadcastType"BT"
"BT'1'!"#rangeOfDNs:
"BT'2'!"#allDNs:
broadcastRange"BR"."BR ssssssssss & tttttttttt !"
# ssssssssss : 10 ASCII Digits from'0'to'9'
representing the starting directory number in the
directory number range (dNRangeStart)
10ASCIIDigitsfrom'0'to'9'representing#tttttttttt:
the ending directory number in the directory
number range (dNRangeStop)
dNList"DN""DN aaaaaaaaaa & bbbbbbbbbb & & zzzzzzzzzz"
# aaaaaaaaaa: 10 ASCII digits from'0'to'9'
representing a directory number.
# bbbbbbbbbb : 10 ASCII digits from'0'to'9'
representing another directory number.
# zzzzzzzzzz: 10 ASCII digits from'0'to'9'
representing the last directory number.
messageRetries"MR"*"MR x!"
# x : 1 ASCII digit from'0'to'9'representing
message delivery retries.
#analog:"ST'0'!"subscriberType"ST"
# ISDN: !"'1'
both:"ST'2' !"
# '3'!""ST
deliveryMode"VM" onHookOniv :"VM'0'!"
# '1'!""VM
both:"VM'2'!"
Table 7 (continued) Parameter Encodings for the
GenericDataMessageDeliveryRequest
and GenericDataMessageDeliveryResponse Structures
Parameter Ptag Parameter Encoding
transmissionFormat"MF". qr30GDMF :"MF'0'!
ar30GDMFWoCS :"MF'1'!
gr30GDMFWoCSMS :"MF'2'!
qr30GDMF2400:"MF'3'!
"MF'4'!#gr30GDMFWoCS2400:
"MF'5'!#gr30GDMFWoCSMS2400:
"MF'6'!"#iSDNChannel:
"MF'7'!"#dSLpacket:
'MF'8'!"#reservedFormat1:
byteFraming"BF"startStopBvteFrammg :"BF'0' !"
"BF'1'!"#noFraming:
requireAckAlerting"RA" no :"RA'0'!"
ves :"RA'1'!"
reportAckAftering"PA"no :"PA'0' !"
yes:"PA'1'!"
#steadyDialTone:"DT'0'!"dialToneType"DT"
messageWaitingDialTone :"DT'1'!"
Dia ! Tone:"DT'2'!"
requireMessageAck"RM"no :"RM'0'!"
ves :"RM'1' !"
reportMessageAck"PM"no :"PM'0'!"
ves :"PM'1' !"
forwardingControl"FC". noForwarding :"FC'0' !"
allowForwardina :"FC'1'!"
disreaardAINTriggers:"FC'2' !"
"FC'3'!"#disregardRerminatingScreening:
#successfulDeliveryOnHook:"RS'0'!"resultType"RS"
# '1'!""RS
alertingACKReceived :"RS'2'!"
"RS'3'!"#messageACKReceived:
"RS'4'!"#dNOutsideNPANXX:
portedNumber :"RS'5'!"
failuretoDeliverRetriesExceeded :"RS'6' !"
# '7'!""RS
"RS'8'!"#dNUnassigned:
# '9'!""RS
"RS' < '!"#accessLineNotAllowed:
# '='!""RS
"RS' > '!"#errorInRequestMessage:
ISDN Access Interface
In accordance with my invention, the second way central server 402 and
originating SPCS 406 exchange message requests and responses is
through an ISDN Message Desk Interface (MDI). Similar to the ISDN
interface between the terminating SPCS and subscriber, the MDI
interface uses ISDN Non
Call Associated Signaling (NCAS) to transfer data. Under MDI access,
central server 402 first establishes a NCAS connection with
originating SPCS 406 through the use of an ISDN Q. 931 SETUP message,
the purpose of which is to obtain a non-call associated call reference
to be used for the duration of the data delivery transaction. All
subsequent ISDN D-channel messages exchanged between the central
server and originating SPCS related to the current transaction use the
same call reference. Upon completion of the transactions, the central
server relinquishes use of the non-call associated call reference and
releases the NCAS connection.
* The GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures are transferred between
central server 402 and originating SPCS 406 through the Facility
Information Element (the encoding of which is described below). The
initial request (i. e., the first
GenericDataMessageDeliveryRequest structure sent by the central
server) is transferred to originating
SPCS 406 in either the initial NCAS SETUP message or through a
subsequent FACILITY message. All subsequent
GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures are transferred between
central server 402 and originating SPCS 406 through a FACILITY
message.
Regarding the specific encoding of the
GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures within the Facility
Information Element, each is encapsulated within the"Service
Component"field. This encapsulation is performed through one of two
methods. Under the first method, the structures are directly encoded
using the"Basic Encoding Rules."
For this method, a new"Protocol Profile"code must be defined (e. g.,
10101). Under the second method, the Remote Operations Service Element
(ROSE) procedures are followed. Under these procedures, the
GenericDataMessageDeliveryRequest structure is encoded as a
ROSE"Invoke"
Component and tagged as a ROSE Operation. The genericDataMessage and
deliveryControlInfo structures are encoded as ROSE arguments. The
GenericDataMessageDeliveryResponse structure is encoded as either a
Return Result Component or Return Error Component to indicate a
successful or failed delivery, respectively. The
GenericDataMessageDeliveryResponse elements are encoded as
ROSE arguments.
3.3 Network Transport
Reference will now be made to how generic data message requests and
responses are transported between originating SPCS 406 or central
server 402 (when the central server has a CCS/SS7 interface) and
terminating SPCS 416. As indicated earlier, the GDMT system uses the
CCS/SS7 network to transport data through the PSTN network.
Specifically, the originating SPCS or central server and terminating
SPCS encapsulate the GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures into TCAP messages and
transport these messages using the existing CCS/SS7 network
infrastructure.
The use of the CCS/SS7 network and TCAP-messaging has several
advantages over the prior art. First, the CCS/SS7 network provides a
true network capability that allows the central server to reach any
subscriber without requiring a direct interface with every SPCS in the
network. Second, the
CCS/SS7 network is a true data network and is therefore not hindered
by the limited bandwidth of the
PSTN voice trunks. Third, TCAP messaging is non-circuit related and
can be transmitted without establishing a call, thereby avoiding
call-setup delays. Lastly, as is further discussed below under the
current invention, the GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures are encapsulated into
the TCAP message without requiring the intermediate network nodes to
have specific knowledge of the data.
The following sections will first generally discuss transport over the
CCS/SS7 network. Next, the embedding of the
GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures into TCAP messages is
discussed. Finally, the routing of generic data request and response
messages over the CCS/SS7 network is discussed with respect to both a
single subscriber destination and broadcast.
Message Transport Over the CCS/SS7 Network
Under one embodiment of the GDMT system, central server 402 accesses
the PSTN through originating SPCS 406 (through an SMDI or MDI
interface), as presented above. Under a second embodiment, central
server 402 accesses the PSTN through STP 508 through CCS/SS7 interface
440.
Each of these embodiments is discussed below.
With respect to the first embodiment, GDMT Subsystem 506 within
originating SPCS 406 accepts generic data message requests from
central server 402 and embeds these requests, including both the
genericDataMessage and deliveryControlInfo structures, into a TCAP
message (assuming the message is destined for a subscriber (s) on
another SPCS). GDMT Subsystem 506 addresses the message based on
the"pilot DN"as specified by central server 402 and then transfers the
message to
STP 508 via CCS/SS7 interface 510. STP 508 resolves the"pilot DN"for
local number portability issues and subsequently delivers the message
to GDMT Subsystem 512 within terminating SPCS 416 through CCS/SS7 link
516. GDMT Subsystem 512 subsequently delivers the genericDataMessage
to the subscriber based on the deliveryControlInfo, as described
above. With respect to response messages,
GDMT Subsystem 512 formulates the response structure, embeds the
structure within a TCAP message, and transfers the response to GDMT
Subsystem 502 via STP 508. GDMT subsystem 502 subsequently passes the
response to central server 402 via SMDI/MDI interface 442.
With respect to the second embodiment, central server 402 formulates
the request structure, embeds this structure directly into a TCAP
message, addresses the message based on the subscriber's directory
number, and transfers the TCAP message directly to STP 508 through
CCS/SS7 interface 440, thereby completely bypassing originating SPCS
406. STP 508 and terminating SPCS 416 subsequently handle the request
and response messages as described above with the exception that STP
508 passes the
TCAP message containing the response directly to central server 402
rather than originating SPCS 406.
Formattiiig of the TCAP Message
Reference will now be made to the embedding of the
GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures into a TCAP message. In
general, TCAP messages are composed of three sub-units called
the"Transaction Portion,"the"Dialogue Portion,"and the "Component
Sequence Portion."The"Dialogue Portion"is unimportant for the purposes
of my invention and is optional. The"Transaction Portion"and"Component
Portion"are further discussed below with reference to each GDMT
structure.
The TCAP encoding of the GenericDataMessageDeliveryRequest structure
is shown in Table 8 (only the value portion of each element has been
shown). The"Transaction Portion"consists of a "Package Type
Identifier"and a"Transaction ID."The"Package Type
Identifier"determines the exchange type and should be set to"Query
with Permission."The"Transaction ID"is used to associate the TCAP
message with a specific application transaction. It is assigned by
originating SPCS 406 or central server 402, if central server 402 has
direct connectivity to the CCS/SS7 network, and is used in all
messages (request and response) related to a particular generic data
message request.
Although TCAP allows multiple components to be stacked into
the"Component Sequence
Portion", the GDMT system uses only one component per TCAP message.
For the
GenericDataMessageDeliveryRequest structure,"Component Type"is set
to"Invoke Component
Last."The"Invoke Component-Last"component consists of a"Component
ID,"an"Operation Code" (consisting further of the"Operation
Family"and"Operation Specifier"), and a"Parameter Set."The "Operation
Family"should be set to"Report Event Family Code"with a value
of"1001010", the most significant bit being set to indicate that a
response is required. The"Operation Specifier"should be set to a new
value called the"GDMT Specifier", defined as"00000011", to indicate
that a generic data message is to be delivered to one or more
destination directory numbers. The"Parameter Set"contains the
GenericDataMessageDeliveryRequest structure, which is coded as either
a single new parameter or optionally as a set of parameters. Again,
knowledge of the specific service application information is not
needed to encode the information in the"Parameter Set". In addition,
the"Parameter Set"is not examined by network nodes during transmission
of the TCAP message. As a result, once again, intervening nodes of the
PSTN network do not require embedded knowledge of specific service
application information.
Table 8: TCAP Encoding of the GenericDataMessageDeliveryRequest
Structure
Sub-Unit Type Sub-Unit Fields Value
Transaction Portion Package Type Identifier"Query with Permission"
Transaction ID"Originating Transaction ID"
Dialogue Portion (OPTIONAL)
Component Component Type"Invoke Component-Last"
Sequence Portion Component ID"Component ID"
Operation Operation Family"Report Event Family Code" (1001010)
Code Operation"GDMT Specifies" (00000011)
Specifier
Parameter Set GenericDataMessageDeliveryRequest
Structure (includes
genericDataMessage and
deliveryControllnfo)
The TCAP encoding of the GenericDataMessageDeliveryResponse structure
is shown in Table 9 (only the value portion of each element has been
shown). The"Package Type Identifier"should be set
to"Response."The"Transaction ID"is set to the same value as the
transaction ID in the corresponding generic data request in order to
relate the response with the request.
The"Component Type"is set to one of two values,"Return Result-Not
Last"and"Return
Result-Last.""Return Result-Not Last"is used if more than one response
message relating to the same transaction is sent by the terminating
SPCS to the originating SPCS or central server (e. g., the terminating
SPCS individually acknowledges delivery of a broadcast message to
multiple subscribers).
"Return Result-Last"is used to indicate the last response in a
sequence of responses or if only one response is being sent to the
originating SPCS or central server (e. g., the terminating SPCS
batches all acknowledgments to a broadcast in a single
GenericDataMessageDeliveryResponse structure). Neither "Component
Type"contains an"Operation Code". Similar to the
GenericDataMessageDeliveryRequest structure, the
GenericDataMessageDeliveryResponse structure is coded as either a new
parameter or optionally as a list of parameters.
Table 9: TCAP Encoding of the GenericDataMessageDeliveryResponse
Structure
Sub-Unit Type Sub-Unit Fields Value
Transaction Portion Package Type Identifier"Response"
Transaction ID"Responding Transaction ID"
Dialogue Portion (OPTIONAL)
Component Component Type"Return Result-Not Last or Return Result
Sequence Portion Last
Component ID"Component ID"
Parameter Set GenericDataMessageDeliveryResponse
Structure (may include multiple responses)
Routing of TCAP Messa2es TlzrouQh the CCSlSS7 Network
Reference will now be made to the routing of TCAP messages containing
GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures through the CCS/SS7
network. As indicated earlier, the GDMT system supports delivery of
generic data messages from the central server to a single subscriber
or to multiple subscribers, through a broadcast capability. With
respect to broadcast, the central server sends one message to each
terminating SPCS that serves subscribers that are to be reached and
the terminating SPCS in turn broadcasts the message based on the
broadcast instructions specified in the deliveryControlInfo structure
(as described in section 3.1). This broadcast method is more efficient
than prior art systems wherein individual messages would need to be
sent to every individual subscriber.
Whether a message is destined for a single subscriber or multiple
subscribers through broadcast, the GDMT system uses
the"pilotDN"parameter as the directory number by which TCAP messages
containing message requests are routed through the CCS/SS7 network.
For the single subscriber case, the pilotDN is the subscriber's
address. For the broadcast case, the pilotDN is based on the method of
broadcast. Specifically, when broadcast is through a"list"or"range"of
directory numbers, the pilotDN is populated with a single random
directory number from the"list"or"range". When broadcast is through
all directory numbers within a single NPA-NXX, the pilotDN is an
arbitrary number within the
NPA-NXX.
Having chosen a value for the pilotDN, originating SPCS 406 or central
server 402 sets the
TCAP routing parameters as follows. The"destination point code"is set
to the point code of STP 508 and the"origination point code"is set to
the point code of originating SPCS 406 or central server 402,
depending on the origin of the message. The GDMT system may require
Global Title Translation (GTT) because originating SPCS 406 or central
server 402 may not know the destination point code of terminating SPCS
416 or the SubSystem Number (SSN) that identifies GDMT subsystem 512.
(If the central server knows the destination point code of terminating
SPCS 416 and the SSN of GDMT subsystem 512, there is no need to use
GTT). When GTT is required, it is enabled by setting the SCCP "Called
Party Address Parameter"as follows. The"Routing Indicator"and"Global
Title Indicator" fields of the"Address Indicator"should be set to
indicate that routing takes place on global title. The "Global
Title"of the"Called Party Address"field should be set such that
the"Address"is the first 6 or 10 digits of the pilotDN and
the"Translation Type"is preferably"251" (since this value has already
been defined for CLASS services, or a new Translation Type can be
used). Lastly, the SCCP"Calling
Party Address Parameter"should be set to the SSN and signaling point
code of originating SPCS 416 or central server 402, depending on the
origin of the message.
Upon configuring the routing parameters of the TCAP message,
originating SPCS 406 or central server 402 sends the message to STP
508, which first determines if the pilotDN is ported and then
subsequently completes GTT. The handling of number portability is
slightly different depending on whether the request message is
destined for a single subscriber or multiple subscribers. Under both
scenarios, STP 508 uses the pilotDN (i. e., the contents of the"Called
Party Address"parameter) to determine whether the corresponding
NPA-NXX is portable by performing a table look-up within the
STP. If the NPA-NXX is portable, STP 508 proceeds to launch a query to
LNP Database 514 where a full 10-digit look-up on the pilotDN is
performed to determine if that particular directory number has ported.
If the number has ported, LNP Database 514 returns to STP 508 the
Local Routing Number (LRN) of the new terminating SPCS. Following the
LNP analysis, or if the NPA-NXX is not portable, or if the pilotDN is
not ported, STP 508 follows normal routing procedure and completes the
GTT by determining and populating the SSN and the destination point
code of terminating SPCS 416. The
GenericDataMessageDeliveryRequest TCAP message is then sent to
terminating SPCS 416.
When the request message is destined for a single subscriber,
terminating SPCS 416 delivers the message using the directory number
specified in the deliveryControlInfo structure, as specified earlier.
Upon completing delivery of the message, terminating SPCS 416
formulates a
GenericDataMessageDeliveryResponse structure to report success or
failure and encapsulates the response in a TCAP response message,
which is addressed/routed back to originating SPCS 406 or central
server 402.
Because of LNP related issues, the handling of broadcast messages by
terminating SPCS 416 is slightly different than that of single
subscriber messages. The PSTN is designed to perform LNP queries and
route CCS/SS7 messages based on a single directory number. The PSTN
has no present capabilities to perform multiple queries on a list or
range of directory numbers. As a result, STP 508, as was discussed
above, performed LNP analysis on a pilotDN that was used to represent
the broadcast list.
Although an LNP query is performed, other directory numbers in the
broadcast list, range, or NPA-NXX may have ported to SPCS's other than
the SPCS serving the pilotDN representing the list. As a result, as
terminating SPCS 416 attempts to deliver the generic data message to
the directory numbers specified in the list, range, or entire NPA-NXX,
the SPCS may encounter a directory number (s) that have been ported
and it no-longer serves. In this case, terminating SPCS 416 generates
a
GenericDataMessageDeliveryResponse TCAP message back to central server
402 using the response code,"portedNumber,"along with a list of
directory numbers that did not receive the message because they were
ported. Since each of these directory numbers requires an LNP query to
properly route it to its serving SPCS, central server 402 generates
(i. e., repeats) individual
GenericDataMessageDeliveryRequest messages for each ported number
using the single number addressing mode. TCAP messages with single
number addressing will always be routed to the correct destination
SPCS. An intelligent central server could record when a directory
number is reported as having been ported and only apply single number
addressing for generic data messages destined to it in the future.
4.0 A First Specific GDMT Service Application Example
Reference will now be made to a specific service, called Deluxe
Messaging Notification
Service, in accordance with my invention and based on the GDMT
invention described above. Again, the advantage of my invention is
that once deployed, it allows complex and diverse services, like the
Deluxe Messaging Notification Service, to be completely implemented at
the end-points of the network within the subscriber equipment and
a"central server"without modification to expensive and difficult to
modify network devices.
The Deluxe Messaging Notification Service, as shown in Figure 7, is an
advanced network feature that complements Unified Messaging services.
Under this service, multi-functional server 704 (i. e., central
server) is dually connected to PSTN 706, using one of the GDMT
interfaces described above, and to Internet 702 using, for example a
TCP/IP connection. Multi-functional server 704 supports a Unified
Messaging Service whereby it receives voice and fax messages from PSTN
706 over interface 716, and email, faxes, pages, short text messages,
and"Internet Telephony"based voicemails from Internet 702 through
Internet connection 714. Whenever a new message is left for a
subscriber of the service, multi-function server 704 notifies the
subscriber by transferring"notification data"to terminating SPCS 708
and subsequently to a screen based device 712 on the subscriber's
access line using the methods described under the current invention.
The screen-based device could be an enhanced caller ID device, an ADSI
or Internet screen-phone, an ISDN phone, a set top box, or a personal
computer, etc.
The GDMT system makes it possible for multi-functional server 704 to
provide the subscriber with (1) a visual or audible alert that new
messages are waiting; (2) an indication of both the type and number of
messages waiting (e. g., 6 voicemail, 3 email, 1 fax, 2 pages); (3)
information on who sent the message (e. g., the calling party number,
the calling party name, or the sender's email address); (4)
information on the message subject (e. g., the email subject header, a
short voice-to-text conversion of a voicemail originator's verbal
response to a prompted voicemail purpose tag line); and, (5) message
detail (e. g., the date and time the message was received, the
duration of the message, the size of an email message, the message
priority, etc.). The advantage of the Deluxe Messaging Notification
Service is that rather than constantly checking the multi-functional
server for messages, subscribers are notified on a CPE device that
messages are waiting.
In addition, multi-functional server 704 could support"Community
Notification"Services", "Push Information Services,"and"ADSI Service
Script Upgrades"based on the GDMT system.
Through Community Notification Services, multi-functional server 704
could notify selective groups of subscribers of pending weather
conditions, missing children, etc. by sending community notifications.
Under"Push Information Services,"corporations could send sale-adds,
stock quotes, etc. to multifunctional server 704 as is done today
under push technologies. In turn, multi-functional server 704 would
send the information to corresponding subscribers of the service.
Under"ADSI Service Script
Upgrades,"multi-functional server 704 could send ADSI script upgrades
to ADSI based phones.
5.0 A Second Specific GDMT Service Application Example
In another embodiment of my invention, the GTT routing table at a STP
could be updated such the generic request messages are routed to a
monitor or service profiler. Under the monitor application, a
monitor-system would terminate the generic request message from a
central server and analyze its contents. Subsequent to the analysis,
the monitor system would regenerate the request message to its
original intended destination, as if it was originating from the
central server. All generic response messages generated by the
terminating SPCS would likewise terminate at the monitor, which would
subsequently regenerate them to the central server. The monitor-system
could perform such functions as authorizing, delaying, and tracking
generic request messages before they are forwarded to their intended
destination.
Under the service profiler application, a service profiler system
would terminate the generic request messages, extract the generic data
contents, and forward the generic data contents to a pager or wireless
device over a wireless network.
6.0 Specific GDMT AIN Example
In accordance with my invention, a new AIN function
called"Send~GDM"can be created to transport generic data messages
between AIN elements, such as service control points and service
switching points. The SendGDM function would contain the content of
the generic data message and the delivery instructions. As
demonstrated for the SMDI and MDI interfaces, the ASN. 1
GenericDataMessageDeliveryRequest and
GenericDataMessageDeliveryResponse structures can be readily encoded
to suit the needs of an AIN message.
APPENDIX
Table of Definitions *DSL: Digital Subscriber Loop # INDN : Integrated
Services Digital Network # GDMF : Generic Data Message Format *GDMT:
Generic Data Message Transport # GTT : Global Title Translation *LNP:
Local Number Portability LRN: Local Routing Number 'MDI: Message Desk
Interface *MDMF: Multiple Data Message Format *NCAS: Non-Call
Associated Signaling # PSTN : Public Switched Telephone Network # SCP
: Service Control Point *SDMF: Single Data Message Format # SMDI :
Simplified Message Desk Interface # SPCS : Stored Program Control
System *SSN: SubSystem Number # STP : Signaling Transfer Point # TCAP
: Transaction Capabilities Application Part I1TT: Utility Telemetry
Trunk
_________________________________________________________________
Data supplied from the esp@cenet database - l2
Claims
What is Claimed is:
1. A method for delivering generic data from a service application
residing on a central server to a subscriber device by means of a
Public Switched Telephone Network (PSTN) wherein the PSTN consists of
a CCS/SS7 signaling network, a transport network, an originating
Stored Program Controlled
System (SPCS), a terminating SPCS, and a Signaling Transfer Point
(STP), wherein the central server interfaces the PSTN through the
originating SPCS and the subscriber device interfaces the PSTN through
the terminating SPCS, and wherein the PSTN has no embedded knowledge
of the generic data or service application residing on the central
server, said method comprising the steps of:
defining a request message at the central server wherein the request
message contains the generic data and data delivery instructions
specified by the service application instructing the terminating SPCS
on how to deliver the generic data to the subscriber device;
addressing the request message based on the subscriber's PSTN address;
transporting the request message from the central server to the PSTN
over the originating SPCS -central server interface;
transporting the request message from the originating SPCS to the STP
via a Transaction
Capabilities Application Part (TCAP) message;
routing the request message based on the subscriber PSTN address to
the terminating SPCS;
extracting the generic data and data delivery instructions from the
request message;
transporting the generic data from the terminating SPCS to the
subscriber device over the terminating SPCS-subscriber device
interface based on the data delivery instructions specified by the
service application;
defining a response message at the terminating SPCS wherein the
response message contains status data indicating the status of the
delivery of the generic data to the subscriber device;
transporting the response message from the terminating SPCS to the
originating SPCS through the STP via a TCAP message;
transporting the response message to the central server over the
originating SPCS-central server interface; and
delivering the status data to the service application.
2. The method of claim 1 wherein the originating SPCS-central server
interface is a Simplified
Message Desk Interface.
3. The method of claim 1 wherein the originating SPCS-central server
interface is a Non-call
Associated Signaling Integrated Services Digital Network interface.
4. The method of claim 1 wherein the terminating SPCS-subscriber
device interface is a GR30-CORE interface.
5. The method of claim 1 wherein the terminating SPCS-subscriber
device interface is a Noncall Associated Signaling Integrated Services
Digital Network interface.
6. The method of claim 1 wherein the terminating SPCS-subscriber
device interface is a
Digital Subscriber Loop Interface.
7. The method of claim 1 wherein the step of routing the generic
request message includes the steps of:
determining if the NPA-NXX of the subscriber address has been ported;
querying a Local Number Portability Database for a Local Routing
Number if the NPA-NXX has been ported; and
routing the request message based on the Local Routing Number if the
subscriber address has been ported.
8. The method of claim 1 wherein the subscriber device interfaces the
PSTN through the originating SPCS.
9. The method of claim 1 wherein transporting the generic data to the
subscriber device occurs regardless of whether the subscriber device
is off-hook or on-hook.
10. The method of claim 1 wherein transporting the generic data to the
subscriber device does not require subscriber interaction.
11. The method of claim 1 wherein a call is never established between
the central server and the subscriber device.
12. The method of claim 1 wherein the central server interfaces the
PSTN through the STP, wherein the step of transporting the request
message from the central server to the PSTN occurs through the
STP-central server interface, and wherein the step of transporting the
response message from the
STP to the originating SPCS to the central server occurs from the STP
to the central server through the
STP-central server interface.
13. The method of claim 1 wherein the subscriber device is owned by a
residential subscriber.
14. The method of claim 1 wherein the subscriber device is owned by a
business subscriber.
15. The method of claim 1 wherein the step of transporting the generic
data to the subscriber device further includes the step of over-riding
vertical services defined for the subscriber device based on the data
delivery instructions
16. A method for broadcasting generic data from a central server to a
plurality of subscriber devices by means of a Public Switched
Telephone Network (PSTN) wherein the PSTN consists of a
CCS/SS7 signaling network, a transport network, an originating Stored
Program Controlled System (SPCS), a terminating SPCS, and a Signaling
Transfer Point (STP), wherein the central server interfaces the PSTN
through the originating SPCS and the subscriber devices interface the
PSTN through the terminating SPCS, and wherein the originating SPCS,
terminating SPCS, and STP have no embedded knowledge of the generic
data said method comprising the steps of:
defining a request message at the central server wherein the request
message contains the generic data and data delivery instructions
whereby the delivery instructions specify to the terminating
SPCS a list of subscriber devices served by the SPCS that should
receive the generic data and the means by which the generic data
should be delivered to these subscriber devices;
addressing the request message with a PSTN address of one of the
subscriber devices specified in the list of subscriber devices;
transporting the request message from the central server to the PSTN
over the originating SPCS -central server interface;
transporting the request message from the originating SPCS to the STP
via a Transactions
Capabilities Application Part (TCAP) message;
routing the request message based on the subscriber PSTN address to
the terminating SPCS;
extracting the generic data and delivery instructions from the request
message; and
transporting the generic data based on the data delivery instructions
to the list of subscriber devices.
17. The method of claim 16 wherein the list of subscriber devices
specified in the request message is specified as a range of PSTN
addresses.
18. The method of claim 16 wherein the list of subscriber devices
specified in the request message is specified as all numbers within a
NPA-NXX available on the terminating SPCS.
19. The method of claim 16 wherein transporting the generic data to
each subscriber device occurs regardless of whether the subscriber
interface is off-hook or on-hook.
20. The method of claim 16 wherein transporting the generic data to
each subscriber device does not require subscriber interaction.
21. The method of claim 16 wherein the plurality of subscriber devices
interface the PSTN through the originating SPCS.
22. The method of claim 16 wherein the plurality of subscriber devices
are owned by residential subscribers.
23. The method of claim 16 wherein the plurality of subscriber devices
are owned by business subscribers.
24. The method of claim 16 wherein a call is never established between
the central server and the plurality of subscriber device.
25. The method of claim 16 wherein the plurality of subscriber devices
are served by a plurality of terminating SPCS's, said method further
comprising the steps of :
separating the subscriber devices based on their terminating SPCS;
defining a plurality of request messages at the central server, one
request message per terminating SPCS, wherein the request message
contains the generic data and data delivery instructions whereby the
delivery instructions specify to the terminating SPCS a list of
subscriber devices served by the SPCS that should receive the generic
data and the means by which the generic data should be delivered to
these subscriber devices;
addressing each request message with a PSTN address of one of the
subscriber devices specified in its corresponding list of subscriber
devices;
transporting each request message to its terminating SPCS; and
transporting, at each terminating SPCS, the generic data based on the
data delivery instructions to the corresponding list of subscriber
devices.
26. The method of claim 25 wherein a community notification service
resides on the central server, said method broadcasting community
notification information to the plurality of subscriber devices.
27. The method of claim 16 further including the steps of:
recording at the terminating SPCS the list of individual subscriber
devices to which the terminating SPCS could not deliver the generic
data because said subscriber devices had been ported;
defining a response message at the terminating SPCS containing the
individual subscriber devices that did not receive the generic data;
transporting the response message from the terminating SPCS to the
originating SPCS through the STP via a TCAP message;
transporting the response message to the central server over the
originating SPCS-central server interface;
defining a plurality of request messages at the central server, one
for each subscriber device specified in the response message, wherein
the request message contains the generic data and data delivery
instructions;
addressing the plurality of request messages based on the PSTN address
of each subscriber address; and
delivering the plurality of generic request messages to the subscriber
devices.
28. The method of claim 27 wherein the central server interfaces the
PSTN through the STP, wherein the step of transporting the request
message from the central server to the PSTN occurs through the
STP-central server interface, and wherein the step of transporting the
response message from the
STP to the originating SPCS to the central server occurs from the STP
to the central server through the
STP-central server interface.
29. A method for delivering generic data from a central server to a
subscriber device by means of an originating Stored Program Controlled
System (SPCS), a terminating SPCS, and a packet router, wherein the
originating SPCS, terminating SPCS, and packet router have no embedded
knowledge of the generic data, said method comprising the steps of :
defining a request message at the central server wherein the request
message contains the generic data and data delivery instructions
instructing the terminating SPCS on how to deliver the generic data to
the subscriber device;
transporting the request message from the central server to the
originating SPCS, to the packet router, and to the terminating SPCS
without establishing a call; and
delivering the generic data to the subscriber device based on the data
delivery instructions.
30. The method of claim 29 further including the steps of:
recording in a response message the status of the delivery of the
generic data to the subscriber; and
transporting the response message from the terminating SPCS to the
packet router to the originating SPCS to the central server.
31. A method for broadcasting generic data from a central server to a
plurality of subscriber devices by means of an originating Stored
Program Controlled System (SPCS), a terminating SPCS, and a packet
router, wherein the originating SPCS, terminating SPCS, and packet
router have no embedded knowledge of the generic data, said method
comprising the steps of:
defining a request message at the central server wherein the request
message contains the generic data and data delivery instructions,
whereby the delivery instructions specify to the terminating
SPCS a list of subscriber devices served by the SPCS that should
receive the generic data and the means by which the generic data
should be delivered to these subscriber devices;
transporting the request message from the central server to the
originating SPCS, to the packet router, and to the terminating SPCS
without establishing a call;
delivering the generic data based on the delivery instructions to the
list of subscriber devices;
recording in a response message the status of the delivery of the
generic data to the subscribers; and
transporting the response message from the terminating SPCS to the
packet router to the originating SPCS to the central server.
32. A system for delivering generic data from a service application
residing on a central server to a subscriber device by means of a
Public Switched Telephone Network (PSTN) wherein the PSTN consists of
a CCS/SS7 signaling network, a transport network, an originating
Stored Program Controlled
System (SPCS), a terminating SPCS, and a Signaling Transfer Point
(STP), wherein the central server interfaces the PSTN through the
originating SPCS and the subscriber device interfaces the PSTN through
the terminating SPCS, and wherein the PSTN has no embedded knowledge
of the generic data or service application residing on the central
server, said system comprising:
means for defining a request message at the central server wherein the
request message contains the generic data and data delivery
instructions specified by the service application instructing the
terminating SPCS on how to deliver the generic data to the subscriber
device;
means for addressing the request message based on the subscriber's
PSTN address;
means for transporting the request message from the central server to
the PSTN over the originating SPCS-central server interface;
means for transporting the request message from the originating SPCS
to the STP via a
Transaction Capabilities Application Part (TCAP) message;
means for routing the request message based on the subscriber PSTN
address to the terminating
SPCS;
means for extracting the generic data and data delivery instructions
from the request message;
means for transporting the generic data from the terminating SPCS to
the subscriber device over the terminating SPCS-subscriber device
interface based on the data delivery instructions specified by the
service application;
means for defining a response message at the terminating SPCS wherein
the response message contains status data indicating the status of the
delivery of the generic data to the subscriber device;
means for transporting the response message from the terminating SPCS
to the originating SPCS through the STP via a TCAP message;
means for transporting the response message to the central server over
the originating SPCScentral server interface; and
means for delivering the status data to the service application.
33. A system for broadcasting generic data from a central server to a
plurality of subscriber devices by means of a Public Switched
Telephone Network (PSTN) wherein the PSTN consists of a
CCS/SS7 signaling network, a transport network, an originating Stored
Program Controlled System (SPCS), a terminating SPCS, and a Signaling
Transfer Point (STP), wherein the central server interfaces the PSTN
through the originating SPCS and the subscriber devices interface the
PSTN through the terminating SPCS, and wherein the originating SPCS,
terminating SPCS, and STP have no embedded knowledge of the generic
data said system comprising:
means for defining a request message at the central server wherein the
request message contains the generic data and data delivery
instructions whereby the delivery instructions specify to the
terminating SPCS a list of subscriber devices served by the SPCS that
should receive the generic data and the means by which the generic
data should be delivered to these subscriber devices;
means for addressing the request message with a PSTN address of one of
the subscriber devices specified in the list of subscriber devices;
means for transporting the request message from the central server to
the PSTN over the originating SPCS-central server interface;
means for transporting the request message from the originating SPCS
to the STP via a
Transactions Capabilities Application Part (TCAP) message;
means for routing the request message based on the subscriber PSTN
address to the terminating
SPCS;
means for extracting the generic data and delivery instructions from
the request message; and
means for transporting the generic data based on the data delivery
instructions to the list of subscriber devices.
34. The system of claim 33 further comprising:
means for recording at the terminating SPCS the list of individual
subscriber devices to which the terminating SPCS could not deliver the
generic data because said subscriber devices had been ported;
means for defining a response message at the terminating SPCS
containing the individual subscriber devices that did not receive the
generic data;
means for transporting the response message from the terminating SPCS
to the originating SPCS through the STP via a TCAP message;
means for transporting the response message to the central server over
the originating SPCScentral server interface;
means for defining a plurality of request messages at the central
server, one for each subscriber device specified in the response
message, wherein the request message contains the generic data and
data delivery instructions;
means for addressing the plurality of request messages based on the
PSTN address of each subscriber address; and
means for delivering the plurality of generic request messages to the
subscriber devices.
35. A method for enhancing Unified Messaging Services comprising a
multi-functional server interfaced to both a PSTN and an Internet, a
subscriber device interfaced to the PSTN through a terminating SPCS,
and wherein the multi-functional server receives voice and fax
messages from the
PSTN and email, faxes, pages and Internet-based voicemail messages
from the Internet, said method comprising the steps of :
defining a request message at the multi-functional server upon
receiving a new PSTN or Internet based message, wherein the request
message contains data indicating both the type and number of PSTN and
ISDN based messages waiting, and wherein the request message contains
delivery instructions instructing the terminating SPCS on how to
deliver the data to the subscriber device;
transporting the request message from the multi-functional server to
the terminating SPCS without establishing a call; and
delivering the data to the subscriber device based on the data
delivery instructions.
36. The method of claim 35 wherein commercial Web servers are
interfaced to the Internet, said method further comprising the steps
of:
pushing data from the commercial Web servers to the multi-functional
server; and
wherein the defined request message contains the data pushed from the
commercial Web Server.
AMENDED CLAIMS
[received by the International Bureau on 15 December 2000 (15.12.00);
original claims 31-36 replaced by amended claims 31-36; new claims
37-43 added; remaining
claims unchanged (5 pages)]
transporting the response message from the terminating SPCS to the
packet router to the
originating SPCS 10 the central server.
31. The method of claim 29 wherein a user of the subscriber device
establishes a voice-band
connection as a result of receiving the generic data.
32. The method of claim 31 wherein the subscriber retrieves data over
the voice-band
connection.
33. The method of claim 29 wherein the subscriber device automatically
establishes a voice
band connection as a result of receiving the generic data.
34. The method of claim 33 wherein the subscriber retrieves data over
the voice-band
connection.
35. A method for broadcasting generic data from a central server to a
plurality of subscriber
devices by means of an originating Stored Program Controlled System
(SPCS), a terminating SPCS, and
a packet router, wherein the originating SPCS. terminating SPCS, and
packet router have no embedded
knowledge of the generic data, said method comprising the steps of :
defining a request message at the central server wherein the request
message contains the
generic data and data delivery instructions, whereby the delivery
instructions specify to the terminating
SPCS a list of subscriber devices served by the SPCS that should
receive the generic data and the means
by which the generic data should be delivered to these subscriber
devices ;
transporting the request message from the central server to the
originating SPCS, to the packet
router. and to the terminating SPCS without establishing a call;
delivering the generic data based on the delivery instructions to the
list of subscriber devices;
recording in a response message the status of the delivery of the
generic data to the subscribers;
and
transporting the response message from the terminating SPCS to the
packet router to the
originating SPCS to the central server.
36. A system for delivering generic data frorn a service application
residing on a central server to a subscriber device by means of a
Public Switched Telephone Network (PSTN) wherein the PSTN consists of
a CCS/SS7 signaling network a transport network, an oric . inaung
Slored Program Controlled
System (SPCS), a terminating SPCS. and a Signaling Transfer Point
(STP), wherein the central server interfaces the PSTN through the
originating SPCS and the subscriber device interfaces the PSTN through
the terminaung SPCS, and wherein the PSTN has no embedded knowledge of
the generic data or service application residing on the central
server, said system comprising :
means for defining a request message at the central server wherein the
request message contains the generic data and data delivery
instructions specified by the service application instructing the
terminating SPCS on how to deliver the generic data to the subscriber
device ;
means for addressing the request message based on the subscriber's
PSTN address ;
means for transporting the request message from the central server to
the PSTN over the originating SPCS-central server interface;
means for transporting the request message from the originating SPCS
to the STP via a
Transaction Capabilities Application Part (TCAP) message;
means for routing the request message based on the subscriber PSTN
address to the terminating
SPCS;
means for extracting the generic data and data delivery instructions
from the request message;
means for transporting the generic data from the terminating SPCS to
the subscriber device over the terminating SPCS-subscriber device
interface based on the data delivery instructions specified by the
service application;
means for defining a response message at the terminating SPCS wherein
the response message contains status data indicating the status of the
delivery of the generic data to the subscriber device;
means for transporting the response message from the terminating SPCS
to the originating SPCS through the STP via a TCAP message;
means for transporting the response message to the central server over
the originating SPCScentral server interface; and
means for delivering the status data to the service application.
37. A system for broadcasting generic data from a central server to a
plurality of subscriber devices by means of a Public Switched
Telephone Network (PSTN) wherein the PSTN consists of a
CCS/SS7 signaling network, a transport network, an originating Stored
Program Controlled System (SPCS), a terminating SPCS, and a Signaling
Transfer Point (STP), wherein the central server interfaces the PSTN
through the originating SPCS and the subscriber devices interface the
PSTN through the terminating SPCS. and wherein the originating SPCS,
terminating SPCS, and STP have no embedded knowledge of the generic
data said system comprising :
means for defining a request message at the central server wherein the
request message contains the generic data and data delivery
instructions whereby the delivery instructions specify to the
terminating SPCS a list of subscriber devices served by the SPCS that
should receive the generic data and the means by which the generic
data should be delivered to these subscriber devices;
means for addressing the request message with a PSTN address of one of
the subscriber devices specified in the list of subscriber devices;
means for transporting the request message from the central server to
the PSTN over the originating SPCS-central server interface ;
means for transporting the request message from the originating SPCS
to the STP via a
Transactions Capabilities Application Part (TCAP) message;
means for routing the request message based on the subscriber PSTN
address to the terminating
SPCS;
means for extracting the generic data and delivery instructions from
the request message; and
means for transporting the generic data based on the data delivery
instructions to the list of subscriber devices.
38. The system of claim 37 further comprising:
rneans for recording at the terminating SPCS the list of individual
subscriber devices to which the terminating SPCS could not deliver the
generic data because said subscriber devices had been ported;
means for defining a response message at the terminating SPCS
containing the individual subscriber devices that did not receive the
generic data;
means for transporting the response message from the terminating SPCS
to the originating SPCS through the STP via a TCAP message;
means for transporting the response message to the central server over
the originating SPCScentral server interface ;
means for defining a plurality of request messages at the central
server, one for each subscriber device specified in the response
message, wherein the request message contains the generic data and
data delivery instructions;
means for addressing the plurality of request messages based on the
PSTN address of each subscriber address; and
means for delivering the plurality of generic request messages to the
subscriber devices.
39. A method for enhancing Unified Messaging Services comprising a
multi-functional server interfaced to both a PSTN and an Internet, a
subscriber device interfaced to the PSTN through a terminating SPCS,
and wherein the multi-functional server receives voice and fax
messages from the
PSTN and email, faxes, pages and Internet-based voicemail messages
from the Internet, said method comprising the steps of :
defining a request message at the multi-functional server upon
receiving a new PSTN or Internet based message, wherein the request
message contains data indicating both the type and number of PSTN and
Internet based messages waiting, and wherein the request message
contains delivery instructions instructing the terminating SPCS on how
to deliver the data to the subscriber device;
transporting the request message from the multi-functional server to
the terminating SPCS without establishing a call; and
delivering the data to the subscriber device based on the data
delivery instructions.
40. The method of claim 39 wherein commercial Web servers 4re
interfaced to the Internet, said method further comprising the steps
of :
pushing data from the commercial Web servers to the multi-functional
server; and
wherein the defined request message contains the data pushed from the
commercial
Web Server.
41. The method of claim 39 wherein a user of the subscriber device, as
a result of receiving the generic data, establishes a voice-band
connection to the multi-functional server and retrieves the PSTN and
Internet based messages waiting.
42. The method of claim 39 wherein the subscriber device, as a result
of receiving the generic data, automatically establishes a voice-band
connection to the muki-functional server and retrieves the
PSTN and Internet based messages waiting.
43. A method for delivering generic data from a central server to a
wireless device by means of an originating Stored Program Controlled
System (SPCS), a terminating SPCS. a packet router, a service
profiler, and a wireless network, wherein the central server is
interfaced to the originating SPCS and the service profiler is
interfaced to both the terminating SPCS and the wireless network, and
wherein the originating SPCS, terminating SPCS, and packet router have
no embedded knowledge of the generic data, said method comprising the
steps of :
defining a request message at the central server wherein the request
message contains the generic data and data delivery instructions
instructing the terminating SPCS on how to deliver the generic data to
the service-profiler;
transporting the request message from the central server to the
originating SPCS, to the packet router, and to the terminating SPCS
without establishing a call;
delivering the generic data to the service profiler based on the data
delivery instructions; and
delivering the gen
STATEMENT UNDER ARTICLE 19 (1)
Original claims 1 to 30 remain unchanged, claims 31 to 36 are replaced
by amended claims bearing the same numbers, and new claims 7 to 43 are
added to better focus the claims on that which applicant regards as
the invention. The amendments have no impact on the description and
drawings of the application.
_________________________________________________________________
Data supplied from the esp@cenet database - l2
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2025 AOH
