Note: Descriptions are shown in the official language in which they were submitted.
CA 02524014 2009-05-26
20365-5002
Connection Control in a Transit
Telecommunications Network
The present invention relates to a method for controlling,
in particular for establishing and/or releasing, connections
between the transit network terminals of a transit network,
with a central control device, a plurality of transit
network terminals and, optionally, one or a plurality of
internal repeater stations within a transit network, using
transit network communication paths that extend in each
instance between two of the terminals and repeater stations,
control of the communication groups, in particular seizing
and releasing these for connections between terminals, being
effected by the control device on the basis of signaling
information that is exchanged between the station and the
terminals.
The present invention also relates to a control device for
controlling, in particular for establishing and releasing,
transit network communication paths within a transit
network, with a plurality of transit network terminals as
well as, optionally, one or a plurality of internal repeater
stations within the transit network, the communication paths
extending in each instance between two of the terminals
and/or repeater stations, the controller being setup between
the terminals in order to exchange signaling information
with the terminals for processing the signaling information
for appropriate control of the communication routes, for the
purpose of controlling connections, in particular
establishing and releasing connections.
The present invention also relates to a terminal device for
a transit network, with a central control device, for
establishing and releasing connections within the transit
network in conjunction with other transit network terminals
as well as, optionally, one or a plurality of internal
1
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
repeater stations within the transit network, using
communications paths which, in each instance, extend between
the terminal device and one other terminal or a repeater
station, the terminal device being set up to exchange
signaling information with the control device, for
controlling the communication paths, in particular seizing
and releasing these for connections.
Within the context of this disclosure, a transit network is
understood to be a communications network that has no end
stations that are used by network subscribers; in place of
this, access to a transit network is effected exclusively
from other communications networks, this being done through
the terminals of the transit network, which resemble
gateways, for example, on the side of the associated
communications networks. Thus, the terminal of the transit
network is not an end device (of a network subscriber), but
rather an interface device to another communications
network. One familiar example of a transit network is a
satellite system that makes satellite connections available
to other networks and which is accessed from the other
networks on its terminals ("satellite terminals"); a transit
network can, of course, be in the form of a cable network
(e.g., glass-fiber network), a radio network, or a hybrid
network that is made up of a number of network types. What
is important is that the transit network has a central
control center for controlling the communication paths that
make up the network.
In many of the transit networks used at present, in
particular in the current generation of stationary satellite
communications systems (for example, those based on the DVB-
RCS standard), no connection-oriented communication between
satellite terminals is defined. Guaranteed bandwidths on
the satellite link are only provided for services using
constant bit rates. Services that use variable bit rates,
2
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
such as many Internet applications, for example, can only be
operated on the "best-effort" principle. Thus, for many
applications, it is not possible to achieve good quality
service and efficient utilization of satellite capacity.
At present, a start is being made on developing the next
generation of broadband satellite communications systems
that are to be based on an efficient system architecture and
are intended to provide high quality services. It is
intended to use a connection-oriented communications form
for this purpose. A typical architecture for such a
satellite network SAN is shown diagrammatically in Figure 1;
more detailed explanations are contained in the papers
titled "Fast Internet Service via on board processing
satellites: the EuroSkyWay optimized techniques" by G.
Losquardo et al, and "The ESW home gateway supporting IP and
MPEG Services for residential users," by G. Losquardo et al,
from the Proceedings of the 19th AIAA International
Communications Satellite Systems Conference, Tolosa, April
2001.
The principal components of this type of system are a
satellite SAT with onboard processing, a network control
center NCC, as well as a number of satellite terminals ST1,
ST2. The satellite terminals ST1 and ST2 -- which are in
this case ground-based -- (additional terminals ST3, ST4 are
indicated) represents the interface between each associated
subscriber end device TE1, TE2 and/or terrestrial
telecommunications networks TN1, TN2 and the actual
satellite system BSS. The end devices TE1, TE2 or the
networks TN1, TN2 belong to the known communications network
types such as, for example, ISDN, ATM, and the Internet (on
the basis of the IP).
3
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
It is the task of the satellite terminals ST1 and ST2 to
ensure that, when required, connections that are in keeping
with subscriber demands are requested or released by way of
the satellite system. The signaling required for this --
indicated in Figure 1 by the dashed arrows ssg -- are
designated as "internal satellite signaling," or by the
abbreviated form "internal signaling." The network control
centre NCC receives requests for connection by way of the
internal signaling system and decides on the basis of
current system load and the characteristics of the
connection that is desired (such as, for example, bandwidth
and quality) whether or not the new connection can be
accepted. In the case of a positive response, on the one
hand both the satellite terminals that are involved are
informed by way of internal signaling and, on the other
hand, a corresponding command to switch the connection
through is passed to the satellites SAT. Ultimately, the
geostationary satellite SAT makes it possible to switch the
channels scll and scl2 between the satellite terminals ST1
and ST2 directly "on board" i.e., they are linked directly
to a communications path. In this way the traffic data
(e.g., speech and/or video, or other data) are exchanged by
way of "single-hop" communications. As a rule, the
communication paths that are used for this purpose exist
between a satellite terminal and a satellite although, if
required, communication paths from satellite to satellite
can be used (these are the so-called inter-satellite links).
More detailed information on broadband satellite systems can
be obtained on the web site http://www.
analysis.com/default_acl.asp?mode=article&iLeftArticle=30.
Detailed information about specific satellite systems is
also contained in the following web sites:
http://www.euroskyway.it/website/html_eng/index.html with
respect to the EuroSkyWay Systems;
http://www.skybridgesatellite.com with respect to Sky-
4
CA 02524014 2009-05-26
20365-5002
bridge; http://www.analysis.com/
satellite/profiles/WildBlue.htm with respect to WildBlue
(formally iSky); and
http://www.isr.umd.edu/CSHCN/presentations/conferences/
staif99/bravman.pdf with respect to OrbLink.
For controlling (establishing, maintaining, and releasing)
connections in satellite systems, known attempted solutions
provide for the use of protocols that are familiar from
terrestrial digital telephone networks, typically
(broadband)-ISDN based protocols. However, these do not do
justice to the special topology of a satellite network and
are needlessly complex for this special set of problems.
For this reason, it is the objective of embodiments of the present
invention to indicate a way to simplify control of
connections in satellite systems and simultaneously improve
the performance of such systems.
This objective has been achieved in one aspect by using a method as well
as a control device or terminal device of the type referred
to in the introduction hereto; in this, in order to exchange
signaling information, use is made of a signaling protocol
that has at least the following request message types that
corresponds to the SIP Standard:
a message type (corresponding to INVITE) to initiate
a connection,
a message type (corresponding to BYE) to initiate
release of the connection, and
a message type (corresponding to ACK) to confirm a
previous exchange of signaling information,
and at least one response message type (corresponding in
particular to 200) for confirmation reports and/or error
reports.
CA 02524014 2011-12-07
54106-68
In another aspect, there is provided a method for controlling connections
between transit
network terminals of a transit network, with a central control device and, a
plurality of
transit network terminals using transit network communication paths that
extend in
each instance between two of the terminals and repeater stations, control of
the
communication groups, being effected by the control device using signaling
information
that is exchanged between the control center and the terminals, wherein a
signaling
protocol with at least the following request message types that correspond to
the
Session Initiation Protocol (SIP) standard is used for exchanging signaling
information: a
message type to initiate a connection setup, a message type to initiate
release of a
connection, and a message type to confirm a previous exchange of signaling
information, as well as at least one response message type for at least one of
confirmation messages and error messages.
In another aspect, there is provided a control device for controlling transit
network
communication paths in a transit network with a plurality of transit network
terminals,
the communications paths each extending between (i) two of the terminals; or
(ii) one or more repeater stations; or (iii) two of the terminals and one or
more
repeater stations, the control device being equipped for exchanging signaling
information with the terminals and for processing the signaling information
for
appropriate control of the communication paths for the purpose of controlling
connections, wherein the control device is equipped for using a signaling
protocol for
the exchange of the signaling information with at least the following request
message
types that correspond to the SIP Standard: a message type for initiating a
connection
setup, a message type for initiating release of the connection, and a message
type
for confirming a previous exchange of signaling information, as well as at
least one
response message type for at least one of confirmation messages and error
messages.
5a
CA 02524014 2011-12-07
54106-68
In another aspect, there is provided a terminal device for a transit network
with a
control device for establishing and releasing connections within the transit
network in
conjunction with other transit network terminals using communications paths
which in
each instance extend between the terminal device and another terminal or a
repeater
station, the terminal device being equipped for exchanging signaling
information with
the control device, for controlling communications paths, wherein the terminal
device
is equipped for using a signaling protocol for the exchange of signaling
information
with at least the following request message types that correspond to the
SIP Standard: a message type for initiating a connection setup, a message type
for
initiating release of the connection, and a message type for confirming a
previous
exchange of signaling information, as well as at least one response message
type for
confirmation messages and/or error messages.
5b
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
Thus, the present invention makes provision for modeling the
messages that are used on the SIP Standard. It is obvious
that the messages must not conform completely to the form
defined in the SIP Standard; a configuration that is
equivalent to this is sufficient given the identical
function of the messages; for example, the name of the
message and/or of the fields in the messages can be
different, or the syntax format can differ. By optimal
matching to a given transit network ~- for example, a
satellite network -- the fields that are not required in
this specific type of transit network can be omitted or
instead of being obligatory can be used "only" optionally.
Using signaling that conforms to the SIP Protocol makes it
possible to achieve surprisingly simple and nevertheless
reliable implementation of the signaling within the transit
network, in particular in a satellite system.
The protocol that is designated with the name SIP (Session
Initiation Protocol) is an IETF standard protocol for
initiating interactive sessions such as video conferencing,
Internet telephony, and instant messaging in an IP-based
network. SIP is based on a standard that has been developed
by the Multiparty-Multimedia-Session-Control-Working Group
(MMUSIC) of the IETF and defined in RFC 3261 (as of June
2002). For further information regarding the SIP Protocol
reference should be made to the SIP website of Henning
Schulzrinne at http://www.es.columbia.edu/"hg/sip/. In
addition to technical background information, this site also
contains an extensive collection of different SIP
implementations, in particular SIP clients and SIP servers.
To the extent that it is necessary in order to understand
the present invention, the following is an overview of SIP
protocol that is based on the web site
http://www.reibold.de/ knowhow/sip.
6
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
SIP is based on the IP protocol and its essential features
are similar to the well-known SMTP and HTTP protocols. Like
these two, SIP uses text based messages in order to
communicate between an SIP client and an SIP server;
requests from the client and responses from the server are
effected by means of these text based messages.
SIP also uses HTTP syntax over long paths. As in the case
of HTTP, SIP requests elicit defined actions on the server
side. There are six methods available for doing this. In
addition, SIP also has its own security mechanisms that are
responsible for the reliability of the messages. Like
HTTP/1.1, SIP can also send a plurality of requests and
responses by way of one TCP, UDP, or SCTP connection. SIP
uses an e-mail-like address in the form user@ domain,
user@ip-address, or telephone number@gateway for addressing
correspondents.
The SIP system recognizes two components: the user agent and
the network server. The user agent is executed at the user
end (e.g., a calling end station). It contains the protocol
-- and is also referred to as the user agent and
client(UAC)-- and a protocol server that is designated as
the user agent server (UAS).The UAC initiates three calls,
the UAS answers incoming calls. There are -- amongst others
-- two different types provided for on the server side:
proxy and redirect server. The SIP proxy server assumes
similar tasks as an SMTP server or an HTTP proxy. It
receives requests from clients, determines the destination
to which these are to be routed, and then passes on the
requests. The redirect server is responsible for messages
to the recipient. It receives requests and informs the
client with which server the agent should make contact. In
this regard, SIP always resorts to the DNS (Domain Name
Service) when it is appropriate to seek out another server.
7
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
As is the case with HTTP, a distinction is made between SIP
requests and SIP responses. An SIP request consists of
three parts: a start line (request lines or status lines),
header fields of a fixed format and content, as well as
(after a blank line) a message body (or body for short) that
consists of one or more body fields. The various header
fields contain information about call services, addresses,
and protocol features. SIP defines six request types:
INVITE, BYE, OPTIONS, ACK, REGISTER, and CANCEL.
The most important request type is INVITE, which is
responsible for initiating a call between client and server.
Using this method, a caller can "invite" a called party to a
telephone call. The information that is contained in the
associated header fields is very similar to that used when
sending an electronic message. Amongst other things, it
passes on the address of the calling party and the address
of the called party, subject, priority, and routing
information. The body of the message can optionally contain
MIME-coded contents, for example, SMIL or XML contents.
Location information as to where an SIP client can be
reached is passed to an SIP server by the REGISTER method.
This is done so that incoming messages from one or more
communications partners can be passed on to the appropriate
client.
BYE ends a session between two terminals. ACK confirms a
reliable exchange of messages and CANCEL attempts to erase a
previously sent request. OPTIONS can contain optional
information about the user.
In addition, SIP lays down six groups of status messages for
responses; each of these is designated with a three-place
number (lxx, 2xx, 3xx, 4xx, 5xx, Gxx).
8
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
However, not all of the message types defined in the SIP
Standard are absolutely necessary for the present invention;
rather, the above-coded message types (INVITE, BYE, ACK, and
200) guarantee the fundamental functions of the present
invention. Naturally, the solution according to the present
invention permits the signaling protocol to make provision
for even more request- and/or response-message types that
corresponds to the SIP Standard, in particular the
following:
a message type (corresponding to CANCEL) to interrupt
establishment of a connection;
a message type (corresponding to REGISTER) to log on a
satellite terminal in the satellite telecommunications
system;
- one or more message types (corresponding, in
particular, to 100-and/or 4xx and/or 5xx responses) for
answers of a non-conclusive type, as well as error
reports that refer to a satellite terminal or the
server.
Such message types can be advantageous, depending on the
actual implementation.
If the present invention is used for satellite systems (for
which it was developed in the first place), its advantages
become relevant to a particular extent. In this case, what
is involved is the control of connections between the
satellite terminals of a satellite telecommunications
system, with at least one satellite, using satellite
communication paths which extend in each instance between a
satellite terminal and a satellite, or between two
satellites. Control of the satellite communications paths
is managed from the control device during the exchange of
signaling information with the satellite terminals, and for
processing signaling information for appropriate control of
satellite communication paths.
9
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
One preferred development of the present invention permits
the establishment of point-to-multipoint sessions, to which
the particular properties of a transit network and in
particular a satellite system, especially the broadcast
functionality of the satellite, as well as the architecture
underlying the satellite system, all comply. To this end it
is expedient if the naming of a plurality of called
terminals is permissible in the messages exchanged according
to the signaling protocol, in particular messages according
to the message type for initiating the establishment of
communications (INVITE), such messages being used for
controlling point-to-multipoint connections.
More advantageously, in order to provide for the economic
processing of error messages, an additional response message
type can be used, with which an error message is signaled to
all the called (satellite) terminals of a point-to-
multipoint connection. In addition, body fields based on an
additional body-field type can be used in the confirmation
reports for point-to-multipoint connections, or at least in
some of these, with an error report relating to a called
(satellite) terminal of the point-to-multipoint connection
being signaled by means of each such body field.
In one particularly simple version, the signaling protocol
can be realized as a signaling protocol that is superimposed
on the IP Protocol, and/or on a protocol such as TCP or UDP
that is of a higher order.
In order to satisfy the special requirements of a connection
within a transit network, it is useful if, within the body
of a request message that is sent from one terminal to the
control station, it is permissible to quote the details of
the desired or required connection parameter. The
connection parameter transmitted in this way can apply in
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
particular the one or a plurality of the following
variables: connection type, service category, maximal data
rate, utilization factor, maximal burst size, desired
priority of the connection, cell delay variation, maximal
cell transfer delay.
In a preferred embodiment of the present invention -- in
particular in a satellite system -- the assignment of
bandwidths for data transmission is controlled on the part
of the satellite or satellites by dynamic resource
management as a function of the connection quality that is
required, so as to arrive at an optimal loading and thereby
improve the quality of connection. When this is done, the
resource management associated with a satellite can be
conducted as part of an on-board system on this satellite.
The present invention together with additional advantages
will be described below on the basis of a non-restrictive
embodiment shown in the drawings appended hereto. These
drawings show the following in diagrammatic form:
Figure 1: a satellite communications network with on-board
processing;
Figure 2: the establishment of a point-to-point connection
within the network shown in Figure 1;
Figure 3: the release of a connection as in Figure 2;
Figure 4: the establishment of a point-to-multipoint
connection;
Figure 5: the partially successful establishment of a point-
to-multipoint connection;
Figure 6: the expansion of a point-to-multipoint connection;
Figure 7: release of the connection shown in Figure 4;
Figure 8: ISDN interworking based on the signal exchange
shown in Figure 2.
11
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
The present invention can be used for different types and
architectures of a transit network. A satellite network SAN
with a broadband satellite system BSS of the type shown in
the introduction to this description on the basis of Figure
1 underlies the exemplary embodiment. As has already been
discussed, such a BSS incorporates a geostationary satellite
SAT with onboard processing, a central network control
centre NCC that is a control device in the sense of the
present invention, and a number (typically several thousand)
of satellite terminals ST1, ST2, ST3, ST4, which in the
present example are ground-based and can operate using
various transmitting and receiving capacities.
As part of its on-board processing system, the satellite SAT
incorporates dedicated, dynamic resource management. This
is responsible for the actual assignment of bandwidths for
transmitting data. If a connection has been successfully
made, resource management provides information to the effect
that a connection with specific connection qualities exists
between the participating satellite terminals. Resource
management is thereby instructed to allocate bandwidths (as
defined in the connection quality for the transmission of
data to these terminals whenever such terminals wish to
transmit data. The allocation of resources is thus effected
to the satellite link dynamically, which is to say exactly
when the satellite terminal needs these resources. When the
satellite is sending no data, these resources can be used
for other connections.
The present invention uses the SIP standard in accordance
with IETF Standard RPC 3261 (Standard SIP) as a departure
point. Proceeding from this standard, within the framework
of the present invention described herein, the Protocol is
optimized for use in the described satellite architecture.
When this is done, the similarity of the satellite
architecture to an SIP network with proxy service is
12
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
exploited. An SIP proxy server can establish connections
between different SIP end devices (e.g., SIP telephones).
The tasks of the control center NCC are very similar to
those of an SIP proxy server. The satellite terminals ST1,
ST2 correspond to the SIP end devices within the SIP
network. The modified SIP Protocol that results from this
can thus be designated as Sat-SIP.
Because of the special architecture of the satellite network
used here as a basis, the following simplifications to Sat-
SIP are proposed:
1. Sat-SIP functions with significantly fewer header fields
in the messages than Standard-SIP. Concretely, only the
following head fields are necessary in Sat-SIP: accept,
allow, error-info, from, to, cseq, call-id, expires and
retry-after, as well as the three header fields for
authentication: WWW-authenticate, authorization, and
authentication-info.
2. Sat-SIP functions with significantly fewer messages than
Standard SIP. Concretely, only the following messages are
provided for in Sat-SIP: ACK, BYE, CANCEL, INVITE, REGISTER,
100, 10, as well as 4xx and 5xx messages. In Sat-SIP, the
same names for the individual message types are used as in
Standard-SIP, although other designators could be used
without impairing the functionality of the protocol.
In contrast to this, Sat-SIP is meant to permit the
following extension of functionality as compared to
Standard-SIP:
- support of point-to-multipoint (ptmp) sessions. In the
case of a ptmp connection, one calling and a plurality of
called terminals are involved. The methods for establishing
and releasing such connections, as well as for adding or
13
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
removing subscribers, are defined in Sat-SIP. These methods
are described in greater detail below. Naturally, the Sat-
SIP protocol (like the Standard-SIP) supports the
establishment and release of point-to-point (ptp) sessions,
which is to say those between one calling and one called
terminal.
- use of an access control method for connections, namely
the CAC that is discussed below, which in this instance
monitors authorization of connections within the satellite
system SAN. Corresponding locations are provided in the
connection establishment and connection release processes in
which such a method is to be incorporated. However, it can
remain open as to which specific method is used.
- configuration of a resource control system. In the
connection establishment and connection release processes
there are corresponding locations at which such a
configuration is to be incorporated. Since various resource
control systems can be used in different satellite systems,
Sat-SIP leaves it open as to the specific manner in which
the control functions. Resource control can be provided in
the control center NCC and/or on board, which is to say on
this satellite, as is known, for example, from the EuroSky-
Way System. The advantage of the latter variant lies in the
fact that the signal run times are shorter and resource
request can be handled quicker, which can make up for the
disadvantage of the greater complexity of onboard systems.
The following changes and developments with respect to
messages and header fields are proposed for the
implementation of these extended features:
1. New body fields can be incorporated in the INVITE
message; these make it possible to transport parameters for
14
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
describing connection quality. These body fields replace
the SDP body that is provided in the Standard-SIP.
2. One or more terminals can be cited in the header field
"to," which is used to designate the end device that is
called. In the event that the more than one terminal is
cited, a ptmp connection is established. (In the Standard-
SIP, only one end device can be specified within the header
field.)
3. One additional body field ("4xx Final Response," short
form "4FIN") has been introduced; to the extent that it is
required, this is used especially in the case of ptmp
connections.
4. A new message (499 "All Terminals Failed") has been
introduced especially for ptmp connections. This message
must contain 4FIN body fields.
The body fields referred to in Paragraph 1 above are used
especially so that a satellite terminal can inform the
control center NCC about the characteristics of the required
connection. Parameters other than those contained in the
SDP body in the case of connections of the Standard-SIP are
required in order to describe these characteristics. In the
exemplary embodiment, the following parameters are used to
describe the connection characteristics that are requested:
connection type (unidirectional or bidirectional; ptp or
ptmp), service category, maximal data rate, utilization
factor (the ratio between average and maximal data rate),
maximal burst size (the maximal quantity of data to be sent
at one time), desired priority of the connection, cell delay
variation, maximal cell transfer delay. In the case of
bidirectional connections, all the features -- with the
exception of the connection type -- can be quoted for each
connection direction.
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
The extended features referred to in Paragraphs 2 to 4 above
relate to ptmp connections and will be discussed in greater
detail below.
16
CA 02524014 2009-05-26
20365-5002
For this reason, using Sat-SIP:
"connection awareness" is established in the satellite
terminals ST1 and ST2, as well as in this central
control center NCC;
this connection awareness, in conjunction with a
suitable method such as the CAC, is used for
authorizing new calls into the system; and
- resource control of the satellite system is configured
in keeping with the newly established connection. With
this configuration, a new user-data connection is
established between the satellite terminals, so that
these can begin to transmit useful data via the
satellite.
As has been discussed, a method for authorizing connections
within the satellite network has been set up in the control
center NCC; in this disclosure, this is referred to as CAC
("Connection Admission Control"). The CAC is typically in
the form of a computer program, although in principle it can
also be a hardware unit. Based on a statistical example,
the CAC decides whether on not a requested connection can be
authorized on the basis of current load, without prejudicing
the service quality of existing connections or endangering
them. If the decision that is reached is positive, the
connection is established. If not, establishment of the
connection is abandoned. A method of this kind is
described, for example, in EP 1 146 763 A2.
CAC is extremely advantageous, above all in the high-load
area, although it requires connection awareness. It should
be mentioned that CAC is not an essential element of the
present invention. Rather, in a simplified embodiment of
17
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
the present invention, it is possible to dispense with CAC
if the advantage of guaranteed service quality for accepted
connections is not required.
In principle, the SAT-SIP Protocol can control ptp sessions
in the same way as the Standard-SIP Protocol. As has been
described above, to this end it is essential that the
messages and finite-state machines that are defined in the
SIP standard be used. The essential additional features are
consideration of the procedures for quality assurance (QoS,
Quality of Service) and resource management insofar as the
prerequisites have been created by the SAT-SIP Protocol in
order to support these proceedings efficiently in a
satellite system. From the standpoint of the protocol
defined in a SIP-Standard, QoS and resource management are
to be covered by other protocols, since only the application
view is decisive for the Standard SIP.
As has been discussed already, however, an essential
additional feature compared to the standard SIP are the ptmp
sessions. Whereas the standard SIP Protocol always sets up
multipoint sessions ("multicast sessions") as a plurality of
ptp sessions (for example, by way of a conference bridge),
the present invention can more favorably use another
solution that is also realized in the Sat-SIP. The
possibility of the ptmp is very well suited for this because
of the broadcast functionality of the satellite and the
underlying architecture.
The signaling messages are transported from the satellite
terminals ST1 or ST2 through a dedicated signaling channel
(not shown in the drawing), to the so-called RASC (" Random
Access Channel") by way of the satellite SAT (omitted from
Figure 2 and Figure 3 for the sake of clarity) to the
control centre NCC, or from there by way of the satellites
to the relevant satellite terminal ST1 or ST2. The RASC is
18
CA 02524014 2011-05-04
54106-68
a channel that is not collision free and can be realized,
for example, using the known ALOHA or slotted-ALOHA method.
Within the control center NCC, based on the QoS and traffic
parameters that have been transmitted, a decision is made as
to whether or not the new connection can be authorized
within the communications network. Authorization follows if
the QoS of all the connections already existing within a
network will not be prejudiced. Procedures of this kind are
already familiar from the prior art.
Figure 2 shows the message flow for a successful ptp call
setup in a signal-sequence diagram. Within the signal
sequence diagrams, the time axis extends vertically
downward, and the messages that are exchanged between the
different points, which are symbolized as vertical lines,
are shown as arrows. In this disclosure, three-place
reference numbers are used for the messages exchanged in the
signal sequence diagrams, the second figure indicating the
satellite terminal ST (n=1,. . . ,4), with which the message
is exchanged, and the third indicates the type of message
(e.g., a final figure 1 indicates an INVITE message).
The messages P11-P24 are exchanged in the process shown in
Figure 2. The following assumptions are made for the
messages.
The identification of the NCC that is used internally
within the satellite system is NCCID;
The identification of the satellite terminals ST1, ST2,
ST3, and ST4 are ST1ID, MID, MID, and ST41D;
within the body of the INVITE message there are some,
but not all, of the QoS parameters defined in Sat-SIP
are contained within the body of the INVITE message.
19
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
In one implementation, regardless of the concrete
satellite system, the CAC that is used, and the type of
connection, only the required QoS parameters (all or,
as in this case, only some), are transported within the
body field of the INVITE messages. In addition, in the
case of bidirectional parameters, the QoS parameters
for the forward and return directions on given
separately; in the case of unidirectional connections,
only the parameters for the forward direction are
given. In every case, however, two parameters that
specify the type of connection must be given: ptp
(point-to-point: "True" or "False"). and UNI
(unidirectional: "True" or "False").
- In the interest of better readability, in each instance
the full field designators were used in the messages.
However, like Standard-SIP, Sat-SIP provides for
abbreviating the designators of frequently occurring
fields so as to make the messages shorter. For
example, in place of " From:" a message could contain
simply "f" or "I" in place of "Call-ID."
The setup of a ptp session is initiated by a request p11
"INVITE" from the (calling) satellite terminal ST1. The
successful arrival of the INVITE message is confirmed by a
return message p12 "100." A CAC check is carried out in the
CNC. This is symbolized by the reference C1. If the CAC is
successful, the connection is authorized and resource
management procedures to allocate resources to the
transmission paths are started, and the called satellite
terminal ST2 is informed by an INVITE message p21. If the
call terminal ST2 can accept the connection, it responds
with a 200-message p23 that is returned to the NCC. After
successful conclusion of the resource allocation, the 200-
message p13 is passed on to the calling terminal ST1 that
in its turn acknowledges receipt by an ACK message p14 that,
CA 02524014 2011-05-04
54106-68
as the message p24, is accordingly passed on to the called
terminal ST2. This concludes the call set up and the
satellite terminals can begin with the transmission of
useful information s2l. Depending on the implementation,
e.g., after a successful CAC, the allocation of connection
paths is effected in parallel to the transmission of the
INVITE message p21; however, the confirmation p23 could also
be awaited for this. In contrast to the Standard-SIP, there
is no RINGING message in this sequence.
The timer that is defined in the Standard-SIP is adapted to
take into account the longer signal run times within
satellite networks.
The unsuccessful cases as well as the possibility of
canceling a call setup request proceed taking into account
what has been said above, analogously to those in the SIP-
Standard; for this reason, any discussion of these in this
disclosure is unnecessary.
Figure 3 shows the flow of messages of a successful ptp call
release, e.g., the release of a connection established as in
21
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
Figure 2. The release is initiated by means of a BYE
message p15, p16, which is also acknowledged by a 200-
message p26, p16. The procedure corresponds to the
procedures of the Standard-SIP. The resources that were
allocated in the control center NCC are then released, or
the QoS parameters are reset by a CAC.
Figure 4 shows a successful call setup for a ptmp call.
Other than in the Standard SIP, single ptp sessions on not
connected together for a ptmp session, but the ptmp call is
processed as a whole within the control center NCC. The
INVITE message mll that is sent from the calling satellite
terminal ST1 to the control center NCC, which initiates the
call set up, contains the identifications and the parameters
of all the called satellite terminals ST2, ST3, ST4, that
are to be connected together for the desired ptmp session.
The sequence of the call set up between the calling
satellite terminal ST1 and the control center NCC is
completed in accordance with the procedures of the Standard-
SIP Protocol, which means that the finite-state machines do
not have to be adapted. A further advantage of this is that
the signaling load at the RASC is minimized so that the
probability of collision is reduced. This is an important
requirement for translation paths in satellite networks,
where resources are costly and therefore valuable. In each
instance, individual sub-sessions are set up between the
control center NCC and the called satellite terminals ST2,
ST3, and ST4. These are part of a common ptmp and are
identified by a common call id number.
The called satellite terminals respond with different
backward messages depending on whether the satellite
terminal in question can or cannot participate in the ptmp
session. In the event ofa successful called setup, the
22
CA 02524014 2011-05-04
54106-68
control station NCC concentrates all the backward messages
(200 or 4xx messages) coming from the called terminals.
Thus, the setup of the ptmp session (Figure 4) is effected
similarly to that of a ptp session; for clarification,
reference numbers in the form 3nm are used for the messages
exchanged in Figure 4, Figure 5, and Figure 7, and these
correspond to those in Figure 2 and Figure 3 (in the form
inm). The successful arrival of the INVITE message is
confirmed by means of a backward message m12 "100." A CAC
check C3 is made in the NCC; if this is successful, the
connection is authorized and resource management procedures
are initiated to allocate resources to the transmission
paths; in addition, the called terminals ST2, ST3, ST4 are
informed by INVITE messages m21, m3l, and m41. The called
satellite terminals respond with 200-messages m23, m33, and
m43. These are bundled in a 200 message m13 and passed on to
the calling satellite terminal ST1. The acknowledging ACK
message m14 is transmitted by messages m24, m34, and m44 to
the called satellite terminals, whereupon the satellite
terminals can begin with the transmission of useful
information s4 in the ptmp session.
Figure 5 considers the case in which one of the called
satellite terminals -- for example the terminal ST3 -- does
not participate in the ptmp session. This terminal then
responds with a 486 message (reference symbol m37), whereas
the other terminals, which accept the call, respond with 200
(reference symbols m23, m24). In this case, a 200 message
m13' is transmitted which, in addition, contains in the body
the identification of those terminals that have acknowledged
negatively. For each 4xx; response of an invited satellite
terminal ST3, a 4FIN body field (4FIN for "4xx Final
Response) is appended; this contains the identification of
23
CA 02524014 2011-12-07
54106-68
the declining satellite terminal and the associated 4xx
response type; thus, the 200 message m13' discloses a 4FIN
body field that contains the information that the satellite
terminal ST3 has responded with 486. Thus, in this case,
too, only a 200 message m13' is transmitted at the interface
between the control center NCC and the calling satellite
terminal ST1; this simplifies the finite state machine of
the calling satellite terminal and permits the retention of
the standard machine. In this case, the ptmp session s3 that
is set up in this way does not involve the satellite
terminal ST3. For the remainder, the setup of the session
s3 as in Figure 5 corresponds to the procedure for the
successful set up as described in Figure 4.
If -- referring to Figure 5 -- all of the invited terminals
ST2, ST3, and ST4, respond with a 4xx message m27, m37, a
499 message m17 is drawn up in place of a 200 message m13'.
In the same way as with the m13' message for each 4xx
response to the 499 message m17, a 4FIN body field will be
appended.
In addition, proceedings for involving additional
subscribers a ("Add Party")or the exclusion of individual
subscribers ("Drop Party") can also be supported by the Sat-
SIP Protocol according to the present invention, with
reference to a ptmp session. Figure 6 shows one
example of an add-party procedure, for example, the
subsequent involvement of the satellite terminal.ST3
following the procedure shown in Figure 5 so that,
proceeding from session s3, a session s4' is achieved in
which the terminal ST3 is similarly involved according to
the results shown in Figure 4. This case proceeds like the
setup of a characteristic session (Figure 2) and the
separate messages are designated with the reference symbol
bnm which corresponds to the messages pnm in Figure 2. The
24
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
difference from the procedure shown in Figure 2 is that
during establishment of the ptmp connection as in Figure 5
in the header fields, the value of the parameter cseq is
increased in order to distinguish the sequence as a
characteristic transaction, whereas the parameter callid is
the same. If a number of INVITE messages are used within
the session, for example in order to invite a number of
satellite terminals to a ptmp session or, in this case, to
INVITE a satellite terminal subsequently, each INVITE
message contains the identical callid; in order to be able
to distinguish between the individual INVITE messages, they
contain different cseq values. This corresponds to the
Standard SIP. The same occurs in the case of BYE messages,
whereas in an ACK or CANCEL message the identical cseq as in
the particular associated INVITE message is used. The
INVITE message bll differs from the corresponding p11
message in particular in that it has an empty message body.
Figure 7 shows the successful call setup in the ptmp case.
Once again, all of the information concerning the satellite
terminal that is to be informed is sent to the calling
satellite terminal ST1 in a common BYE message m15; this is
done in order, on the one hand, to use the RASC channel
effectively and, on the other hand, to remain in conformity
with standards. A common acknowledgment m16 is used for the
acknowledgment message. In an unsuccessful case, the body
of the 200 messages is used in order to inform the calling
satellite ST1 of the subscribers who have sent a negative
acknowledgement. As far as the satellite terminals ST2,
ST3, and ST4 are concerned, the procedure is analogous to
that shown in Figure 3; in particular, the messages m25,
m35, and m45 (BYE) and m26, m36, and m46 (200) correspond to
the messages p25 or p26, respectively, shown in Figure 3.
Here, too, the resources allocated in the control center
NCC, are ultimately released by means of a CAC call C4, or
the QoS parameter is reset.
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
QoS and/or traffic parameters can be newly negotiated for an
existing Sat-SIP session, as this information is
communicated from the calling terminal ST1 to the control
center NCC in a new INVITE message. In the event that the
new parameters are accepted by the CAC, the control center
NCC sends appropriate INVITE messages to the called
terminals. As soon as all the called terminals have
responded with a 200 message, the control center NCC sends a
200 message to the calling satellite terminal. This
responds with an ACK message to the control center, which
once again sends an ACK message to each of the called
satellites. Only the calling terminal can initiate
modification of QoS and/or traffic parameters.
The Sat-SIP Call Control Prototype is described at length in
SDL ("Specification and Description Language"). The
architecture of the Sat-SIP Call Control prototype that the
Sat-SIP Protocol implements is oriented essentially on the
functional units required by the SIP Standard. Consequently,
the terminal Sat-SIP software and the control center Sat-SIP
software in the processes are subdivided according to
transaction user, client transaction, and server
transaction. Client and server transactions are described
in the Standard-SIP and with the exception of the adapted
timer, have been incorporated, complete and unmodified, in
Sat-SIP.
In addition, if required for purposes of coordination (for
control of the different process stages), processes that go
beyond the standard must also be introduced. For example,
the SIP Standard describes only the fact that specific tasks
have to be assumed by a certain logical entities, but not,
however, how this is to be done in a specific case. The
same applies to the software architecture of the satellite
terminals.
26
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
Another important point is the matter of the interworking of
SAT-SIP with existing terrestrial protocols, namely,
connection oriented protocols (ISDN, ATM) as well as non-
connection protocols (IP). To this end, a dedicated inter-
working unit is required in the satellite terminal; this
generates an action request either from a message (ISDN,
ATM) arriving in the satellite terminal from the terrestrial
network, or from an incoming packet (IP), or derives the
appropriate parameters from the incoming message and
composes a suitable Sat-SIP INVITE message. If necessary,
mapping the parameters onto the SAT-SIP parameters must take
place within the interworking unit (termination of the
incoming connection), or the incoming messages are
transmitted by way of the speech/data channel that has been
set up. Then, consideration must be given individually to
the special teachers of the particular terrestrial protocol
(timer behaviour in the case of TCP/IP TCP splitting).
Figure 8 shows one example of a signal sequence with inter-
working between the ISDN Protocol and the Sat-SIP protocol.
A Q931.SETUP message has been received by an ISDN inter-
working function IF1 associated with the calling satellite
terminal ST1. The incoming SETUP message is then "held
back" by the IWF in order to check whether or not a
connection request for the anticipated (ISDN) traffic can be
accepted. Only then can the SETUP message be sent on to the
called terminal ST2 or its interworking function IF2. The
interworking function IF1 thus generates a setup request ipl
(setup_req) from the SETUP message that is the trigger to
generate an INVITE message p11. The setup request ipi
contains all the information from the incoming SETUP message
that is required for generating an INVITE message pil (which
is to say essentially the traffic and QoS parameters).
Within the satellite system, the messages p11, p21 and so on
follow in the same way as has been discussed above on the
27
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
basis of Figure 2. On the called side ST2, a setup
indication pil (setup_ind) is generated when the INVITE
message p21 arrives, and this goes to the interworking
function IF2 of the called satellite terminal ST2. Receipt
is acknowledged by a setup response pia (setup_resp). This
contains all the parameters that are required to generate
the 200 message p23, which is then sent back through the
satellites to the calling satellite terminal ST1 as message
p13. Within the calling satellite terminal ST1, a setup
confirmation ip3 (setup_cnf, "setup confirmation") is
generated from this, and this is in its turn acknowledged by
a message ip4 (setup_cmp_req,"setup completion request").
This leads to the transmission of an ACK message p14, p24
which concludes the transaction within the satellite system
(Figure 2. On the called side, the ACK is once again
converted to a confirmation pi4 (setup_cmp_ind "setup
complete indication"). The Sat-SIP session S12 and the
associated voice/data channel are set up through the
satellites.
The Q.931 SETUP message ql that is waiting in the called
interworking function IF1 is now transmitted by way of a
dedicated signaling channel to the called satellite terminal
ST2/IF2(complete separation of signaling and useful
information), and from there passed to a subordinate ISDN
exchange that processes the Q.931 Protocol in the known
manner. When this is done, the signaling channel can be
allocated permanently, for example, by configuration of one
or more satellite terminals, or it is set up as required,
for example, in a manner similar to the method described.
The signaling information for a specific satellite terminal
thus passes through a "single hop." There is now ISDN
signaling that conforms to standard between the two
interworking functions IF1, IF2, the exchange of information
being effected transparently by way of the Sat-SIP session
S12.
28
CA 02524014 2005-10-27
PCT/EP2004/004213 W02004/098146 A2
Signalling for call release is effected in a manner that
corresponds to that discussed above.
The present invention is not restricted to the example of
the Sat-SIP discussed above; rather, it can be used in
general systems. Thus, the present invention can also be
used, for example, with a narrow-band satellite system.
Resource management of the satellite SAT can be either on-
board or localized in the control center NCC. In addition,
the control center NCC does not have to be realized as a
ground location that is separated from the satellite, but
can be on-board either wholly or in part. It is also
possible to use a communications satellite system without
onboard processing." In this case, the data connection is
made in a "double-hop" from the calling satellite terminal
through a central ground station to the called satellite
station.
The connections can also be set up by involving terrestrial
network connections (without satellite) which are signaled
in the same way as in the present invention, e.g., via Sat-
SIP.
29
