EP1618721A2 - Verbindungssteuerung in einem transit-telekommunikationsnetz - Google Patents

Verbindungssteuerung in einem transit-telekommunikationsnetz

Info

Publication number
EP1618721A2
EP1618721A2 EP04739095A EP04739095A EP1618721A2 EP 1618721 A2 EP1618721 A2 EP 1618721A2 EP 04739095 A EP04739095 A EP 04739095A EP 04739095 A EP04739095 A EP 04739095A EP 1618721 A2 EP1618721 A2 EP 1618721A2
Authority
EP
European Patent Office
Prior art keywords
terminal
terminals
connection
satellite
satsip
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04739095A
Other languages
English (en)
French (fr)
Inventor
Edith Dusch
Gerald Karner
Josef Rammer
Ferdinand Schlapansky
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG Oesterreich
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG Oesterreich filed Critical Siemens AG Oesterreich
Publication of EP1618721A2 publication Critical patent/EP1618721A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/18578—Satellite systems for providing broadband data service to individual earth stations
    • H04B7/18589—Arrangements for controlling an end to end session, i.e. for initialising, synchronising or terminating an end to end link
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/03—Protocol definition or specification 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to a method for controlling connections, in particular for establishing and / or clearing down connections, between transit network terminals of a transit network with a central control device, a number of transit network terminals and optionally one or more relay points internal to the transit network of transit network communication routes, each running between two of the terminals and / or relay points, the control of the communication routes, in particular the allocation and release thereof for connections between terminals, being carried out by the control device on the basis of signaling information which is between the control station and the terminals is exchanged.
  • the invention also relates to a control device for controlling, in particular for seizing and releasing, transit network communication routes in a transit network with a number of transit network terminals and optionally one or more relay points internal to the transit network, the communication routes each between two of the terminals and / or relay points run, the control device being set up for exchanging signaling information with the terminals and for processing the signaling information for correspondingly controlling the correlation routes for the purpose of controlling connections, in particular connecting and disconnecting, between the terminals.
  • the invention also relates to a terminal device for a transit network with a central control device, for establishing and clearing the connection in the transit network in cooperation with other transit network terminals and optionally one or more relay points internal to the transit network using communication links, which each run between the terminal device and another terminal or a relay point, the terminal device being set up for exchanging signaling information with the control device for controlling the communication links, in particular for occupying and releasing them for connections.
  • a transit network is understood to mean a communication network which has no end points used by network subscribers; instead, access to a transit network takes place exclusively from other communication networks, specifically via the terminals of the transit network, which often correspond to gateways, for example, on the part of the connected communications networks.
  • a terminal of the transit network is therefore not a terminal (of a network subscriber), but rather an interface device to another Korrimunikationsnetz.
  • a well-known example of a transit network is a satellite system that makes satellite connections available to other networks and whose terminals ("SateJJbltenterrriinals") are accessed from these other networks; a transit network can of course also be used as a cable network (e.g. fiber optic network), radio network or a hybrid network. It is important that the transit network has a central control center for controlling the communication routes running in the network.
  • the main components of this type of system are a satellite SAT with "on-board processing", a network control station NCC ('Network Control Center') and a number of satellite effect terminals ST1, ST2.
  • the - here ground-based - satellite terminals ST1, ST2 represent the interface between the associated subscriber terminals TE1, TE2 and / or terrestrial telecommunication networks TN1, TN2 and the actual satellite system BSS.
  • the connected ones Terminals TE1, TE2 or networks TN1, TN2 belong to the known communication network types, such as ISDN, ATM, Internet (based on the EP).
  • the task of the satellite terminals ST1, ST2 is to ensure that, if necessary, suitable connections are requested or cleared via the satellite system in accordance with the subscriber requests.
  • the signaling required for this - symbolized in FIG. 1 by dotted arrows ssg - is referred to as "internal signaling in the satellite system", or “internal signaling” for short.
  • the control station NCC receives connection requests via the internal signaling system and decides on the basis of the current system load and the characteristics of the desired connection - such as the required bandwidth and quality - whether the new connection can be accepted. In the event of a positive answer, the two affected satellite terminals are informed about internal signaling, on the one hand, and a corresponding command to switch the connection is sent to the satellite SAT.
  • the geostationary satellite SAT makes it possible to switch channels ropes, scl2 between satellite terminals ST1, ST2 directly "on-board", ie they are linked directly to a communication path.
  • the traffic data eg voice and / or video, or other data
  • the communication links used for this usually exist between a satellite terminal and a satellite, but if necessary, communication links from satellite to satellite can also be used (so-called tersatelKte links).
  • a method and a control device or terminal device of the type mentioned at the outset in which a signaling protocol is used for the exchange of the signaling information, with at least the following request message types corresponding to the SIP standard: a message type (corresponding INVITE) for initiating a connection establishment, a message type (corresponding to BYE) for initiating a connection termination, and a message type (corresponding to ACK) for confirming a previous exchange of signaling information, and at least one response message type corresponding to the SIP standard (corresponding in particular 200 ) for confirmation messages and / or error messages.
  • a message type corresponding INVITE
  • BYE message type
  • ACK message type
  • the invention therefore provides for the messages used to be modeled on the SIP standard. It is obvious that the messages do not have to obey the form defined in the SEP standard, but that an equivalent design is sufficient, with the same function of the messages; for example, the names of the messages and / or the fields in the messages may be different, or the syntax format may vary.
  • By optimizing adaptation to a given transit network - e.g. Satellite network - fields that are not required in this specific type of transit network can also be omitted or "instead" can be used instead of being mandatory.
  • the use of signaling in accordance with the SDP protocol enables a surprisingly simple but reliable implementation of the signaling in the transit network , especially in a satellite system.
  • SD? is an IETF standard protocol for initiating interactive 'sessions', such as video conferencing, Internet telephony and instant messaging in an EP-based network.
  • SEP is based on a standard that was developed by the multiparty multimedia session control working group (MMUSI of the IETF and is defined in RFC 3261 (as of June 2002).
  • MUSI multiparty multimedia session control working group
  • SD? is based on the IP protocol and is basically similar to the well-known protocols SMTP and HTTP. How did these two use SD? For the communication between an SD? client and a SEP server, text-based messages are used to implement the client's request and server response.
  • SD? uses HTTP syntax over long distances.
  • SIP also has its own security mechanisms that are responsible for the reliability of the transmission.
  • SEP can also transmit multiple requests and responses via a TCP, UDP or SCTP connection. Does SD use for addressing communication partners? an email-like address representation of the form user @ domain, user @ ip-dress or phone number @ gateway.
  • the SDP system has two components: the user agent and the network server.
  • the user agent is executed by the user (e.g. a calling end station). It contains the protocol client - also called user agent client (UAC) - and a protocol server, which is known as the user agent server (UAS).
  • UAC user agent client
  • UAS user agent server
  • the UAC initiates the calls, the UAS answers incoming calls.
  • proxy and redirect servers are provided (among others): proxy and redirect servers.
  • the SIP proxy server performs similar tasks as an SMTP server or HTTP proxy. It accepts requests from the client, determines where they should be directed to and then forwards the requests.
  • the redirect server is responsible for messages to the recipient. It accepts requests and tells the client which server the agent should contact. SD too? always uses the DNS (Domain Name Service) when it comes to tracking down a different server.
  • DNS Domain Name Service
  • An SD? Request consists of three parts: a start line (request line or status line), header fields with a defined format and content, and (after an empty line) a news trump card (short "body") that consists of one or more body fields
  • the various header fields contain information about call services, addresses and protocol characteristics SD? defines six request types: INVITE, BYE, 0PTI0NS, ACK, REGISTER and CANCEL. 1 -
  • INVITE The most important request type is INVITE, which is responsible for initiating a call between client and server.
  • a caller can "invite" a called party to a phone call.
  • the information contained in the associated header fields are very similar to those when sending an electronic message. Among other things, they transmit the address of the caller and that of the called party, subject, priority and routing information.
  • the body of the message can optionally contain MEVEE-encoded content, for example SMTL or XML content.
  • the REGISTER method is used to transmit location information to an SDP server, where a SIP CHent can be reached, so that incoming answers from one or more communication partners are forwarded to them.
  • BYE ends the session between two terminals.
  • ACK confirms the reliable exchange of messages and CANCEL tries to delete a request that has already been sent.
  • 0PTI0NS can contain optional information about the user.
  • the message types defined in the SIP standard are not all absolutely necessary for the invention; rather, the message types mentioned above (DSTV ⁇ , BYE, ACK and 200) already guarantee the basic functioning of the invention.
  • the solution according to the invention of course allows the signaling protocol to provide further request and / or response message types which correspond to the SIP standard, in particular the following: a message type (corresponding to CANCEL) for interrupting a connection; a message type (corresponding to REGISTER) for registering a satellite terminal in the SatelHten telecommunications system; one or more message types (corresponding in particular to 100 and / or 4xx and / or 5xx responses) for responses of a non-final type and for error messages relating to a satellite terminal or the server.
  • Such further message types can be advantageous depending on the current implementation.
  • the invention is used for satellite systems - for which it was primarily developed - its advantages are particularly evident.
  • the control of the satellite Communication routes Is carried out by the control device by exchanging signaling information with the satellite terminals and for processing the signaling information for corresponding control of the satellite communication routes.
  • a preferred further development of the invention allows the establishment of point-to-multipoint sessions, which meet the special properties of a transit network and in particular a satellite system, in particular the broadcast functionality of the satellite and the architecture on which the satellite system is based.
  • a transit network and in particular a satellite system
  • the broadcast functionality of the satellite and the architecture on which the satellite system is based.
  • it is useful if in the messages exchanged according to the signaling protocol, in particular messages according to the message type for initiating a connection establishment (INVITE), the calling of several called terminals is permitted, such messages being used for the control of point-to-multipoint connections become.
  • an additional response message type can be used for the economical handling of error messages, with which an error message is signaled in relation to all called (SateUiten) terminals of a pure-to-multipoint connection.
  • hull fields according to an additional hull field type can be used in the confirmation messages for point-to-multipoint connections, or at least in some of them, with each such hull field providing an error message relating to a called (satellite) terminal the point-to-multipoint connection in question is signaled.
  • the signaling protocol can be implemented as a signaling protocol based on the D? Protocol and / or a higher-level protocol such as TCP or UDP.
  • connection parameters transmitted in this way can relate in particular to one or more of the following parameters: connection type, service category, maximum data rate, usage factor, maximum burst size, desired priority of the connection, cell delay variation, maximum cell transfer delay. ' ' -
  • the allocation of bandwidths for data transmission on the part of the satellite or satellites is carried out by dynamic resource management as a function of the required controlled connection qualities to achieve optimal utilization and improve the connection quality.
  • the resource management assigned to a satellite can run on this satellite as part of an on-board system.
  • Fig. 2 shows the establishment of a point-to-point connection in the network of Fig. 1;
  • FIG. 3 shows the dismantling of the connection of FIG. 2
  • FIG. 8 shows EDN interworking based on the signal exchange of FIG. 2.
  • the invention can be used for different types and architectures of a transit network.
  • the exemplary embodiment is based on a satellite network SAN with a broadband satellite system BSS of the type shown in the introduction to the description with reference to FIG.
  • a system BSS has a geostationary satellite SAT with "on-board processing", a central network control station NCC, which represents a control device in the sense of the invention, and a number of (typically several thousand) satellite terminals ST1 , ST2, ST3, ST4, which are ground-based in the exemplary embodiment under consideration here and can be equipped with different transmission and reception capacities.
  • the satellite SAT has its own dynamic resource management as part of its on-board processing system. This is responsible for the actual allocation of bandwidth for the transmission of data. If the connection is established successfully, the resource management is informed that there is a connection with a certain connection quality between the participating Satej uten terminals. The resource management is thus instructed to assign these terminals (the bandwidth defined in the connection quality) for the transmission of data whenever the Terrninals want to transmit data.
  • the allocation of resources on the satellite link is thus "dynamic", that is always exactly when a satellite terminal needs these resources. These resources can be used for other connections during the time in which a satellite effector does not send any data.
  • the invention uses the SIP standard as a starting point in accordance with the IETF standard RFC 3261 (“standard SIP”).
  • standard SIP the protocol is optimized within the scope of the invention described here for use in the satellite architecture described.
  • the similarity is thereby reduced of the satellite architecture with an SD? network with proxy server:
  • a SIP proxy server can establish connections between different SEP end devices (eg SDP telephones).
  • the tasks of the control center NCC are those of a SEP proxy server very similar.
  • the satellite terminals ST1, ST2 correspond to the SD? terminals in the SD? network.
  • the resulting modified SD? protocol can thus be called "Sat-SD?" be designated.
  • Sat-SD? manages with far fewer header fields in the messages than standard SEP. Are specific in Sat-SD? only the following header fields are required: 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 ,
  • Sat-SD? comes with much less messages than standard SD? out. Are specific in Sat-SD? only the following messages are provided: ACK, BYE, CANCEL, INVITE, REGISTER, 100, 200, as well as 4xx and 5xx messages. In Sat-SD? are the same names for each message type as in standard SD? used, but other identifiers could also be used without affecting the functionality of the protocol.
  • the resource control can be provided in the control station NCC and / or on-board, i.e. on the satellite, as is the case e.g. is known from the EuroSkyWay system.
  • the advantage of the latter variant is that the signal runtimes are shorter and resource requirements can be dealt with more quickly, which can outweigh the disadvantage of the greater complexity of on-board systems.
  • New trunk fields can be contained in the INVITE message, which allow parameters to be described to describe the connection quality. These fuselage fields replace the SDP fuselage used in standard SD? is provided.
  • One or more terminals can be specified in the to header field, which is used to designate the called terminal. If more than one terminal is specified, a ptmp connection is established. (In standard SD? Only one end device can be specified in the header field to.)
  • connection type unidirectional or bidirectional; ptp or ptmp
  • service category maximum data rate
  • usage factor the ratio between average and maximum data rate
  • maximum burst size maximum amount of data to be sent at once
  • desired priority of the connection cell delay variation, maximum cell transfer delay.
  • the resource control of the satellite system is configured according to the newly established connection.
  • a user data connection is established between the satellite terminals, so that they can begin to transmit user data via the satellite.
  • CAC 'Connection Admission Control'
  • the CAC is typically implemented in the form of a computer program, but in principle it can also be implemented as a hardware unit.
  • the CAC decides e.g. According to a statistical algorithm, whether a requested connection can be permitted based on the current system load, without restricting or endangering the quality of service of existing connections. If the decision is positive, the connection is established. Otherwise the connection establishment will be terminated unsuccessfully.
  • a method of this type is described, for example, in EP 1146763 A2, the content of which is incorporated as part of this disclosure.
  • the CAC is particularly advantageous in the high-load range, but requires a sense of connection. It should be noted that the CAC is not an essential element of the invention. Rather, in a simplified embodiment of the invention, the inclusion of a CAC can be dispensed with if the advantage of guaranteed service quality is not required for accepted connections.
  • the signaling messages are sent from the satellite terminal ST1 or ST2 via their own signaling channel (not shown in the figure), the so-called RASC ('Random Access Channel'), via the satellite SAT (not shown in FIGS. 2 and 3 for clarity) and transported to the control station NCC, or from there via the satellite to the relevant satellite terminal ST1 or ST2.
  • the RASC is not a collision-free channel and can e.g. can be realized using the known ALOHA or slotted ALOHA processes.
  • the control center NCC uses the transmitted QoS and traffic parameters to decide whether the new connection can be permitted in the communication network. Approval is granted if the QoS of all connections already in the network is not impaired. Methods of this type are well known in the art
  • the NCC identifier used internally in the satellite system is NGGID.
  • the identifiers of the satellite title terminals ST1, ST2, ST3 and ST4 used internally in the satellite system are ST1 ID, ST2ID, ST3ID, ST4ID.
  • the ⁇ NVTTE message In the body of the ⁇ NVTTE message are some, but not all, in Sat-SD? contain defined QoS parameters.
  • QoS parameters In an implementation, depending on the specific satellite system, the CAC used and the type of connection, only the required QoS parameters (all or, as in this case, only a part), are transported in the body field of the DSTVi'l ⁇ messages.
  • the QoS parameters for the forward and reverse directions are specified separately; for unidirectional connections, only the parameters for the forward direction are specified.
  • two parameters specifying the connection type must be specified: PTP (point-to-point "true” or "false") and UNI (unidirectional: "true” or "false”).
  • the establishment of a ptp session is initiated by a request pll "INVITE" from the (calling) satellite terminal ST1.
  • a reverse message pl2 "100" confirms the successful arrival of the INVITE message.
  • a NAC is carried out by the NCC; this is symbolized by the reference symbol C1. If the CAC is successful, the connection is permitted, resource management procedures for the allocation of resources on the transmission links are initiated, and the called ST2 terminal is informed by an INVITE message p21. If the called ST2 terminal can accept the connection, it replies with a 200 message p23, which is sent back to the NCC. After successful completion of the resource allocation, the 200 message p!
  • Table 2 shows an example of a set of useful values for a GEO system according to Fig. 1. The set of values is based on the assumption that an unreliable transport layer such as UDP is used, which is why the values for retransmission are also given. Of course, depending on the configuration used (LEO, MEO, GEO, etc.), the values shown are to be adapted to the respective satellite system. Table 2 shows - via standard SD? In addition - a time parameter satT is used, which has the value 500 ms in the example considered. If a reliable transport layer is used, e.g. TCP, or the retransmission is taken over by the physical layer of the satellite protocoU layer model, so (according to standard SD?) The timers for the configuration of the retransmission can be set to the value 0.
  • a reliable transport layer e.g. TCP
  • the timers for the configuration of the retransmission can be set to the value 0.
  • Fig. 3 shows the message flow of a successful ptp call release, e.g. the dismantling of the connection established according to Fig. 2.
  • the breakdown is initiated by a BYE message pl5, pl6, which is also acknowledged by a 200 message p26, pl6.
  • the process corresponds to the processes of the standard SD ?.
  • the resources occupied in the control center NCC are released or the QoS parameters are reset by means of a CAC call C2.
  • Fig. 4 shows a successful call setup for a ptmp call.
  • individual ptp sessions are not interconnected for a ptmp session, but the ptmp call is handled in the control center NCC as a whole.
  • the INVITE message mll sent by the calling satellite effect terminal ST1 to the control center NCC and initiating the call set-up contains the identifications and parameters of all called satellite signals.
  • ST3, ST4 which should be interconnected to the desired ptmp session.
  • the called Satititerminals respond with different backwards messages, depending on whether the relevant Satitite terminal can participate in the ptmp session or not.
  • FIGS. 4 and 5 and 7 The structure of the ptmp session (Fig.4) is thus similar to that of a ptp session (Fig.2);
  • reference symbols of the form 3nm are used for the messages exchanged in FIGS. 4, 5 and 7, which correspond to those in FIGS. 2 and 3 (the form lnm).
  • Table 3 shows the exchanged messages of FIGS. 4 and 5.
  • the successful arrival of the INVITE message is confirmed by a reverse message ml2 "100".
  • the called terminals ST2, ST3, ST4 are informed by INVITE messages m21, m31, m41.
  • the called satellite terminals answer with 200 messages m23, m33, m.43. These are bundled in a 200 message ml3 forwarded to the calling satellite terminal ST1.
  • the acknowledging ACK message ml4 is forwarded to the called satellite terminals by messages m24, m34, m44, whereupon the satellite terminals with the transmission of the useful information s4 in the ptmp session can start.
  • a 4FIN trunk field (4FIN for '4xx Final Response') is added, which contains the identifier of the rejecting Satelu ⁇ enterrninal and the associated 4xx response type;
  • the 200 message ml3 'thus has a 4FIN trunk field with the information that the satellite terminal ST3 has responded with 486.
  • the setup of session s3 according to FIG. 5 corresponds to the process of successful setup as described in FIG. 4.
  • FIG. 6 shows an example of an add-party process, for example the subsequent inclusion of the satellite terminal ST3 following the process of FIG. 5, so that a session s4 'is reached starting from the session s3, in which the terminal ST3 is also integrated is, according to the result of Fig.4.
  • This FaU proceeds like the establishment of a separate session (FIG. 2), and the individual messages are identified by reference characters bnm corresponding to the messages pnm in FIG. The difference to the process in FIG.
  • each INVITE message contains the same callid; In order to be able to distinguish between the individual INVITE messages, they receive different cseq values. This corresponds to the standard SD ?.
  • the ENfVITE message bll differs from the corresponding message pll in particular in that it has an empty message body
  • Fig. 7 shows the successful call reduction in ptmp FaU.
  • all of the information about the satellite terminals to be notified is transmitted to the calling satellite effect terminal ST1 in a common BYE message ml5 in order to use the RASC channel effectively and to remain standard-compliant.
  • For feedback is a common acknowledgment ml6 is used.
  • the body of the 200 message is again used to include those subscribers who have sent a negative receipt to the calling satellite terminal ST1.
  • the process is completely analogous to the process in FIG. 3; in particular, the messages m25, m35, m45 (BYE) and m26, m36, m46 (200) in FIG. 5 correspond to the messages ⁇ 25 and ⁇ 26 of FIG. 3.
  • the resources occupied in the control center NCC are released or the QoS parameters are reset by means of a CAC call C4.
  • QoS and / or traffic parameters can be renegotiated for an existing Sat-SIP session by including this information in a new INVITE message from the calling terminal ST1 to the control center NCC. If the new parameters are accepted by the CAC, the control center NCC sends corresponding INVITE messages to the called terminals. As soon as all called terminals have answered 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 in turn sends an ACK message to each of the SatelHt terminals called. Changing the QoS and / or traffic parameters can only cause the calling terminal.
  • the Sat-SD? CaU Control Prototyp is largely written in SDL ('Specification and Description Language').
  • the architecture of the Sat-SD? CaU Control prototypes that use the Sat-SD? ProtokoU implemented, is essentially based on the SD? Standard functional units required.
  • the Terminal Sat SIP software and the control station Sat SD? Software are subdivided into processes corresponding to Transaction User, CHent Transaction and Server Transaction. CHent and Server Transactions are in standard SD? described and complete and - with the exception of the adjusted timers - unchanged in Sat-SD? accepted.
  • connection-oriented ISDN, ATM
  • connectionless protocols EP
  • SateUitenterminal This requires a separate interworking unit in the SateUitenterminal, which either derives a trigger for a connection request from a message arriving in the satellite terminal from the terrestrial network (ISDN, ATM) or an incoming packet (D?), Or derives corresponding parameters from the arrives incoming message and a suitable Sat-SD? Issues INVITE message. If necessary, the parameters must also be mapped to the Sat-SIP parameters in the interworking unit (termination of the incoming connection), or the incoming messages are transmitted via the established user channel. Special features of the respective terrestrial protocol (timer behavior, with TCP / D? TCP SpHtting) must then be considered individually.
  • FIG. 8 shows an example of a signal sequence with interworking between the ISDN ProtokoU and the Sat-SD? ProtokoU.
  • a Q.931 SETUP message q1 had been received by a jSDNterwork g group DF1 assigned to the calling satellite terminal ST1.
  • the incoming SETUP message is now "held back" by the IWF to check whether a connection request can be accepted for the expected (ISDN) traffic. Only then can the SETUP message be sent to the called terminal ST2 or its interworking terminal.
  • Function D? 2 The interworking function D? L thus generates a setup request ipl (setup_req) from the SETUP message, which is an incentive to generate an INVITE message pll.
  • the setup request ipl contains all information from the incoming SETUP message, which are necessary for the generation of an INVITE message pll (ie essentially the traffic and QoS parameters).
  • an INVITE message pll ie essentially the traffic and QoS parameters.
  • the messages pll, p21 etc. follow in the same way as above with reference to FIG
  • a setup indication pil (setup_ind) is generated on the called side ST2, which is sent to the interworking function D72 of the called party SateUitenterminals ST2 goes.
  • the receipt is acknowledged by a setup response pi3 (setup_resp).
  • the ACK message p24 is again converted into an acknowledgment ⁇ i4 (setup_cmp_ind, 'setup complete indication').
  • the signaling channel can be permanently assigned, for example by configuration, to one or more Satemtenter inals, or it can be set up if necessary, for example, also according to the described method SateUitenterminal thus go through a "single hop".
  • SateUitenterminal thus go through a "single hop".
  • the invention is of course not based on the example of Sat-SD discussed above? limited, rather it can also be used in more general systems.
  • the invention can also be used with a narrowband satellite system.
  • the resource control of the SateUiten SAT can be located on-board or in the control station NCC.
  • the rudder t ation NCC not considered to be realized from SateUiten separate terrestrial SteUe but may be in whole or teüweise on-board.
  • a communication satellite system without "on board processing" can also be used. In this case, the data connection runs in a "double-hop" from the calling satellite terminal via a central ground station to the called satellite terminal.
  • connections including terrestrial network connections (without a satellite unit), which are also signed according to the invention, for example via satellite SD?
  • TabeUe 1 Sat SEP messages of Fig. 2 and 3 (ptp)
  • INVITE satsip NCCID Sat-SIP / 1.0 To: "Terminal ST2" ⁇ satsip: ST2ID> From: "Terminal ST1" ⁇ satsip: ST1ID> Call-ID: 324 & ST1ID CSeq: 1 INVITE
  • INVITE satsip ST2ID Sat-SIP / 1 .0 To: "Terminal ST2" ⁇ satsip: ST2ID> From: "Terminal ST1" ⁇ satsip: ST1 ID> Call-ID: 325 @ ST1 ID CSeq: 1 INVITE
  • TabeUe 4 Sat-SDP messages of FIGS. 6 and 7 ( ⁇ dd-Partv, Prop-Partv)

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Astronomy & Astrophysics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Radio Relay Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Exchange Systems With Centralized Control (AREA)

Abstract

In einem Transitnetz, insbesondere einem Satelliten-Telekon-ununikationssystem, mit einer zentralen Steuereinrichtung (NCC), einer Anzahl Terminals (ST1, ST2, ST3, ST4) und gegebenenfalls einer oder mehreren internen Relaisstellen, insbesondere Satelliten (SAT), wird zum Steuern von Verbindungen - insbesondere zum Verbindungsaufbau und/oder -abbau - zwischen den Terminals unter Verwendung von (Satelliten­-)Kommunikationsstrecken, die jeweils zwischen zwei der Terminals und/oder Relaisstellen verlaufen, Signalisierungsinformation zwischen einer Steuereinrichtung (NCC) und den Terminals ausgetauscht, und zwar gemäss einem Signalisierungsprotokoll mit zunündest folgenden, dem SIP-Standard entsprechenden Request-­Nachrichtentypen: ein Nachrichtentyp (entsprechend INVITE; m11) zum Einleiten eines Verbindungs­ aufbaus, ein Nachrichtentyp (entsprechend BYE; m15) zum Einleiten eines Verbindungsabbaus, und ein Nachrichterttyp (entsprechend ACK; m14) zum Bestätigen eines vorangegangenen Austauschs von Signalisierungsinformation, sowie zumindest einem dem SIP-Standard entsprechenden Response-Nachrichtentyp (m13, m16) für Bestätigungsmeldungen und/ oder Fehlermeldungen.

Description

VERBINDUNGSSTEUERUNG IN EINEM TIIANSΓΓ-TELEKOMMUNII ATIONSNETZ
Die Erfindung betrifft ein Verfahren zum Steuern von Verbindungen, insbesondere zum Verbindungsaufbau und/ oder -abbau, zwischen Transimetz-Terminals eines Transitnetzes mit einer zentralen Steuereinrichtung,, einer Anzahl von Transitnetz-Terminals sowie gegebenenfalls einer oder mehreren, dem Transitnetz internen Relaisstellen, unter Verwendung von Transitnetz-Kornmunikationsstrecken, die jeweils zwischen zwei der Terminals und/ oder Relaisstellen verlaufen, wobei die Steuerung der Kommuriikationsstrecken, insbesondere das Belegen und Freigeben derselben für Verbindungen zwischen Terminals, von der Steuereinrichtung aufgrund von Signalisierungsinformation durchgeführt wird, die zwischen der Steuerstation und den Terminals ausgetauscht wird.
Gleichermaßen betrifft die Erfindung eine Steuereinrichtung zur Steuerung, insbesondere zum Belegen und Freigeben, von Transitnetz-Komm.unikationsstrecken in einem Transitnetz mit einer Anzahl von Transimetz-Terminals sowie gegebenenfalls einer oder mehreren, dem Transitnetz internen Relaisstellen, wobei die Komrnunikationsstrecken jeweils zwischen zwei der Terminals und/ oder Relaisstellen verlaufen, wobei die Steuereinrichtung zum Austausch von Signalisierungsinformation mit den Terminals und zur Verarbeitung der Signalisierungsinformation zur entsprechenden Steuerung der Korj mur kationsstrecken für die Zwecke des Steuerns von Verbindungen, insbesondere des Verbindungsaufbaus und -abbaus, zwischen den Terminals eingerichtet ist.
Ebenso bezieht sich die Erfindung auf eine Terminal-Einrichtung für ein Transitnetz mit einer zentralen Steuereinrichtung, für den Verbindungsauf- und -abbau in dem Transitnetz in Zusammenwirken mit anderen Transitnetz-Terminals sowie gegebenenfalls einer oder mehreren, dem Transitnetz internen Relaisstellen unter Verwendung von Kommunikationsstrecken, die jeweils zwischen der Terminal-Einrichtung und einem anderen Terminal oder einer Relaisstelle verlaufen, wobei die Terminal-Einrichtung zum Austausch von Signalisierungsinformation mit der Steuereinrichtung zur Steuerung der Komrnunikationsstrecken, insbesondere das Belegen und Freigeben derselben für Verbindungen, eingerichtet ist.
Unter Transitnetz wird im Rahmen dieser Offenbarung ein Kommunikationsnetz verstanden, das keine von Netzteilnehmer genutzten Endstellen aufweist; stattdessen erfolgt der Zugang zu einem Transitnetz ausschließlich von anderen Kommunikationsnetzen aus, und zwar über die Terminals des Transitnetzes, denen aufseiten der angebunden Kornmunikati- onsnetze oftmals z.B. Gateways entsprechen. Ein Terminal des Transitnetzes ist somit kein Endgerät (eines Netzteilnehmers), sondern eine Schnittstelleneinrichtung zu einem anderen Korrimunikationsnetz. Ein bekanntes Beispiel eines Transitnetz ist ein Satellitensystem, das anderen Netzen Satellitenverbindungen zur Verfügung stellt und auf dessen Teπriinals („SateJJbltenterrriinals") von diesen anderen Netzen aus zugegriffen wird; freilich kann ein Transitnetz auch als Kabelnetz (z.B. Glasfasernetz), Funknetz oder ein hybrides - aus mehreren Netztypen zusammengesetztes - Netz realisiert sein. Wichtig dabei ist, dass das Transitnetz ein zentrales Steuerzentrum zur Steuerung der im Netz verlaufenden Komrnunikationsstrecken aufweist.
In vielen derzeit verwendeten Transitnetzen, insbesondere in der derzeit aktuellen Generation von stationären Sate tenkorrununikationssystemen (z.B. auf Basis des DVB-RCS Standards), ist keine verbindungsorientierte Kornrnunikation zwischen SatelHtenter inals definiert. Garantierte Bandbreiten auf dem SatelHten-Link sind nur für Dienste mit konstanter Bitrate vorgesehen. Dienste variabler Bitrate, wie z. B. viele Internetanwendungen, können nur nach dem "best-effort" Prinzip bedient werden. Dadurch ist es für viele Anwendungen nicht möglich, sowohl eine gute Dienstqualität als auch eine effiziente Nutzung der Satellitenkapazität zu erreichen.
Es sind derzeit Ansätze zur Entwicklung einer nächsten Generation von Breitband-Satelliten- kommuriikationssystemen bekannt, die auf einer effizienteren Systerrtarchitektur beruhen soll und höherwertige Dienste in besserer Qualität anzubieten gestatten soll. Zu diesem Zweck soll eine verbindungsorientierte Korrirnxrnikationsform verwendet werden. Eine typische Architektur für ein solches Satellitennetz SAN ist in Fig. 1 schematisch dargestellt; weitere Erläuterungen können den Artikeln "Fast Internet Service via on board processing satellites: the EuroSkyWay optimised techniques" von G. Losquadro et al. und "The ESW home gateway supporting EP and MPEG Services for residential users" von G. Losquadro et ah, aus den Proceedings der 19th AIAA International Communications Satellite Systems Conference, Tolosa, April 2001, entnommen werden.
Die Hauptkomponenten dieses Systemtyps sind ein Satellit SAT mit "On-Board Processing", eine Netzwerk-Steuerstation NCC ('Network Control Center'), sowie eine Anzahl von Sateffitenterminals ST1, ST2. Die - hier bodengestützten - Satemtenterrninals ST1, ST2 (weitere Terminals ST3, ST4 sind angedeutet) stellen die Schnittstelle zwischen jeweils zugehörenden Teilnehmer-Endgeräten TE1, TE2 und/ oder terrestrischen Telekorrm unikati- onsnetzen TN1, TN2 und dem eigentlichen Satellitensystem BSS dar. Die angebundenen Endgeräte TE1, TE2 bzw. Netze TN1, TN2 gehören den bekannten Kommitnikationsnetz- Typen, wie z.B. ISDN, ATM, Internet (auf der Basis des EP), an. Aufgabe der SatelHtenterminals ST1, ST2 ist es, dafür zu sorgen, dass bei Bedarf entsprechend den Teilnehmeranfragen geeignete Verbindungen über das Satellitensystem, angefordert bzw. abgebaut werden. Die dazu nötige Signalisierung - in Fig.1 durch gepunktete Pfeile ssg symbolisiert - wird als „Satellitensystem-interne Signalisierung'", oder kurz „interne Signalisierung" bezeichnet. Die Steuerstation NCC erhält Verbindungswünsche über das interne Signalisierungssystem und entscheidet auf Basis der aktuellen Systemauslastung und den Charakteristiken der gewünschten Verbindung - wie z.B. geforderte Bandbreite und Qualität -, ob die neue Verbindung akzeptiert werden kann. Im Falle einer positiven Antwort werden einerseits die beiden betroffenen SatelHtenterminals über interne Signalisierung informiert, andererseits wird ein entsprechender Befehl zum Durchschalten der Verbindung an den Satelliten SAT geschickt. Der geostationäre Satellit SAT schließlich ermöglicht es, Kanäle seil, scl2 zwischen Sateüitenterrrtinals ST1, ST2 direkt "on-board" durchzuschalten, d.h. sie werden direkt zu einem Kornrnunikationsweg verknüpft. Auf diese Weise können die Verkehrsdaten (z.B. Sprache und/ oder Video, oder andere Daten) in 'S gle-Hop'-Ko munikation ausgetauscht werden. Die hierfür verwendeten Kommunikationsstrecken bestehen in der Regel zwischen einem SatelHtenterminal und einem Satelliten, jedoch können bei Bedarf auch Korrununikationsstrecken von Satellit zu Satellit eingesetzt werden (sogenannte tersatelKte-Links).
Tiefergehende Information zu BreitbandsateHitensystemen kann der Web-Seite http : / /www . analysys . com/def ault_acl . asp?mode=article&iLef tArticle=30 entnommen werden, sowie spezifisch über jeweils ein bestimmtes Satellitensystemen folgenden Web-Seiten: http: //www. euroskyway. it/website/html_eng/index. html zu dem EuroSkyWay- System; http: //www. skybridgesatellite. com/ zu Skybridge; http: // www.analysys . com/satellite/profiles/WildBlue . htm zu WildBlue (früher iSky); sowie http: //www. isr. umd . edu/CSHCN/presentations/conferences/staif99/ brav an . pdf zu OrbLink.
Für die Steuerung (Aufbau, Erhalt, Abbau) von Verbindungen in Satellitensystemen sehen die bekannten Lösungsansätze die Verwendung von Protokollen vor, die von terrestrischen digitalen Telefonnetzen her bekannt sind, und zwar typischerweise (Breitband-)ISDN- basierte Protokolle. Diese werden der speziellen Topologie eines Satellitennetzwerks allerdings nicht gerecht und sind für diese spezielle Problemstellung unnötig komplex.
Es ist daher Aufgabe der Erfindung, einen Weg zur Vereinfachung und zugleich Leistungssteigerung für die Verbindungssteuerung in Satellitensystemen aufzuzeigen. Diese Aufgabe wird von einem Verfahren sowie einer Steuereinrichtung bzw. Terminal- e nrichtung der eingangs genannten Art gelöst, bei welchen für den Austausch der Signalisierungsinformation ein Signalisierungsprotokoll verwendet wird, mit zumindest folgenden, dem SIP-Standard entsprechenden Request-Nachrichtentypen: ein Nachrichtentyp (entsprechend INVITE) zum Einleiten eines Verbindungsaufbaus, ein Nachrichtentyp (entsprechend BYE) zum Einleiten eines Verbindungsabbaus, und ein Nachrichtentyp (entsprechend ACK) zum Bestätigen eines vorangegangenen Aus- tauschs von Signalisierungsinformation, sowie zumindest einem dem SIP-Standard entsprechenden Response-Nachrichtentyp (entsprechend insbesondere 200) für Bestätigungsmeldungen und/ oder Fehlermeldungen.
Die Erfindung sieht somit vor, die verwendeten Nachrichten dem SIP-Standard nachzu- gestalten. Es liegt hierbei auf der Hand, dass die Nachrichten nicht völlig der im SEP- Standard definierten Form gehorchen müssen, sondern ein diesem äquivalente Gestaltung ausreicht, bei gleicher Funktion der Nachrichten; beispielsweise können die Namen der Nachrichten und/ oder der Felder in den Nachrichten anders lauten, oder das Syntaxformat kann abweichen. Durch optimierende Anpassung auf ein gegebenes Transitnetz - z.B. Satellitennetz - können auch Felder, die in diesem konkreten Transitnetz-Typ nicht benötigt werden, weggelassen oder anstatt verpflichtend „nur" optional verwendet werden. Durch den Einsatz einer dem SDP-Protokoll entsprechenden Signalisierung gelingt eine überraschend einfache und dennoch zuverlässige Implementation der Signalisierung im Transitnetz, insbesondere in einem Satellitensystem.
Das mit dem Namen SD? ('Session Initiation Protocol') bezeichnete Protokoll ist ein IETF- Standardprotokoll zur Initiierung interaktiver „Sitzungen" ('sessions'), wie Videokonferenzen, Internet-Telefonie und Instant-Messaging in einem EP-basierten Netzwerk. SEP beruht auf einem Standard, der von der Multiparty-Multimedia-Session-Control-Arbeitsgruppe (MMUSI der IETF entwickelt wurde und in RFC 3261 (Stand Juni 2002) definiert ist. Für weitere Informationen zum SIP-Protokoll sei auf die SD?- Web-Site von Henning Schulzrinne unter http : //www. cs . columbia . edu/-hgs/sip/ verwiesen. Dort können neben technischen Hintergrundinformationen auch eine umfangreiche Zusammenstellung von unterschiedlichen SlP-Implementierungen, insbesondere SIP-Clients und -Server, entnommen werden.
Im Folgenden wird ein kurzer, auf der Web-Site http: //www. reibold . de/knowhow/sip/ beruhender Überblick über SEP-Protokoll gegeben, soweit dies für das Verständnis der Erfindung erforderlich ist. SD? beruht auf dem IP-Protokoll und ähnelt in seinen Grundzügen auf den wohlbekannten Protokollen SMTP und HTTP. Wie diese beiden verwendet SD? für die Kommunikation zwischen einem SD?-Client und einem SEP-Server textbasierte Nachrichten, mittels derer Requesis („Anforderungen") des Clients und Responses („Antworten") des Servers realisiert werden.
SD? verwendet dabei über weite Strecken auch HTTP-Syntax. SD?-Requests rufen wie bei HTTP definierte Aktionen auf der Serverseite hervor. Dazu stehen sechs Methoden zur Verfügung. SIP verfügt zudem über eigene Sicherungsmechanismen, die für die Zuverlässigkeit der Übermittlung zuständig sind. Wie HTTP/1.1 kann SEP auch mehrere Requests und Responses über eine TCP-, UDP- oder SCTP-Verbindung übermitteln. Für die Adressierung von Konrvmunikationspartnern verwendet SD? eine E-Mail-ähnliche Adressendarstellung der Form user@domain, user@ip-adresse oder telefonnummer@gateway.
Das SDP-System kennt zwei Komponenten: den User Agent und den Netzwerkserver. Der User Agent wird dabei auf Seiten des Anwenders (z.B. einer rufenden Endstelle) ausgeführ Er enthält den Protokoll-Client - auch User Agent Client (UAC) genannt - und einen Protokoll Server, den man als User Agent Server (UAS) bezeichnet. Der UAC initiiert die Anrufe, der UAS beantwortet eingehende Anrufe. Server-seitig sind (unter anderem) zwei unterschiedliche Typen vorgesehen: Proxy- und Redirect-Server. Der SIP-Proxy-Server übernimmt ähnliche Aufgaben wie ein SMTP-Server bzw. HTTP-Proxy. Er nimmt Requests des Clients entgegen, bestimmt wohin sie geleitet werden sollen und leitet anschließend die Requests weiter. Der Redirect-Server ist für Nachrichten zum Empfänger zuständig. Er nimmt Requests entgegen und teilt dem Client mit, mit welchem Server der Agents Kontakt aufnehmen soll. Auch SD? greift dabei immer wieder auf das DNS (Domain Name Service) zurück, wenn es gilt, einen änderen Server aufzuspüren.
Wie bei HTTP unterscheidet man zwischen SD?-Requests und -Responses. Ein SD?-Request besteht aus drei Teilen: einer Startzeile (Request-Zeile bzw. Status-Zeile), Header-Feldern mit fest definierten Format und Inhalten, sowie (nach einer Leerzeile) einem Nachrichtertrumpf (kurz „Rumpf"), der aus einem oder mehreren Rumpffeldern ('body fields') besteht. Die verschiedenen Header-Felder enthalten Informationen über Call-Services, Adressen und Protokoll-Merkmale. SD? definiert sechs Request-Typen: INVITE, BYE, 0PTI0NS, ACK, REGISTER und CANCEL. 1 -
Der wichtigste Request-Typ ist INVITE, die für die Initiierung eines Anrufes zwischen Client und Server verantwortlich ist. Mit dieser Methode kann ein Anrufer einen Angerufenen zu einem Telefonat „einladen". Die Informationen, die in den zugehörigen Header-Feldern enthalten sind, sind denen beim Versand einer elektronischen Nachricht sehr ähnlich. Sie übermitteln unter anderem die Adresse des Anrufenden und die des Angerufenen, Betreff, Priorität und Routing-Informationen. Der Rumpf der Nachricht kann optional MEVEE- kodierte Inhalte enthalten, beispielsweise SMTL- oder XML-Inhalte.
Über die REGISTER-Methode werden an einen SDP-Server Standortinformationen übermittelt, wo ein SIP-CHent zu erreichen ist, damit eintreffende Antworten eines oder mehrerer Korrununikationspartner an diesen weitergeleitet werden.
BYE beendet die Sitzung zwischen zwei Terminals. ACK bestätigt den zuverlässigen Nachrichtenaustausch und CANCEL versucht, einen bereits verschickten Request zu löschen. 0PTI0NS kann optionale Informationen über den Anwender enthalten.
Außerdem legt SD? für Responses sechs Gruppen von Status-Nachrichten fest, die jeweils mit einer dreistelligen Zahl (lxx, 2xx, 3xx, 4xx, 5xx, 6xx) bezeichnet werden.
Die in dem SIP-Standard definierten Nachrichtentypen sind jedoch nicht alle für die Erfindung unbedingt erforderlich; vielmehr garantieren schon die obengenannten Nachrichtentypen (DSTVΠΈ, BYE, ACK sowie 200) das grundsätzliche Funktionieren der Erfindung. Die erfindungsgemäße Lösung lässt selbstverständlich zu, dass das Signalisierungsprotokoll noch weitere Request- und/oder Response-Nachrichtentypen vorsieht, die dem SIP- Standard entsprechen, insbesondere die folgenden : ein Nachrichtentyp (entsprechend CANCEL) zum Unterbrechen eines Verbindungsaufbaus; ein Nachrichtentyp (entsprechend REGISTER) zum Anmelden eines Satellitenterminals im SatelHten-Telekorrununikationssystem; ein oder mehrere Nachrichtentypen (entsprechend insbesondere 100- und/ oder 4xx- und/oder 5xx-Responses) für Antworten nicht-endgültiger Art sowie für ein Satelliten- terminal bzw. den Server betreffende Fehlermeldungen. Solche weiteren Nachrichtentypen können in Abhängigkeit von der aktuellen Implementation vorteilhaft sein.
Wenn die Erfindung für Satellitensysteme - für die sie in erster Line entwickelt wurde - verwendet wird, kommen ihre Vorteile in besonderem Ausmaß zur Geltung. In diesem- Fall geht es somit um das Steuern von Verbindungen zwischen SatelHtenterrninals eines Satelliten-Telekommunikationssystems mit zumindest einem Satelliten unter Verwendung von Sateffiten-Kommunikationsstrecken, die jeweils zwischen einem Satellitenterrninal und einem Satelliten oder zwischen zwei Satelliten verlaufen. Die Steuerung der Satelliten- Kommunikationsstrecken, wird .von der Steuereinrichtung unter Austausch von Signalisierungsinformation mit den SatelHtenterminals und zur Verarbeitung der Signalisierungsinformation zur entsprechenden Steuerung der Sate ten-Kommunikatiorisstrecken durchgeführt.
Eine bevorzugte Weiterbildung der Erfindung gestattet die Errichtung von Punkt-zu- Mehrpunkt-Sitzungen, denen die besonderen Eigenschaften eines Transitnetzes und insbesondere Satellitensystems, insbesondere die Broadcast-Funktionalität des Satelliten sowie die dem Satellitensystem zugrunde liegende Architektur, entgegen kommt. Hierfür ist es zweckmäßig, wenn in den nach dem Signalisierungsprotokoll ausgetauschten Nachrichten, insbesondere Nachrichten nach dem Nachrichtentyp zum Einleiten eines Verbindungsaufbaus (INVITE), die Nennung mehrerer gerufenen Terminals zulässig ist, wobei solche Nachrichten für die Steuerung von Punkt-zu-Mehrpunkt-Verbindungen verwendet werden.
Vorteilhafterweise kann zur ökonomischen Behandlung von Fehlermeldungen ein zusätzlicher Response-Nachrichtentyp verwendet werden, mit dem eine Fehlermeldung in Bezug auf sämtliche gerufenen (SateUiten-)Terminals einer Purikt-zu-Mehrpunkt-Verbindung signalisiert wird. Außerdem können in den Bestätigungsmeldungen für Punkt-zu- Mehrpunkt-Verbindungen, zumindest jedoch in einem Teil von diesen, Rumpffelder nach einem zusätzlichen Rumpffeld-Typ verwendet werden, wobei mittels jedes solchen Rumpffelds eine Fehlermeldung in Bezug auf ein gerufenes (Sate ten-)Terminal der betreffenden Punkt-zu-Mehrpunkt-Verbindung signalisiert wird.
In einer besonders einfachen Variante kann das Signalisierungsprotokoll als auf dem D?- Protokoll und/ oder einem diesen übergeordneten Protokoll, wie TCP oder UDP, aufsetzendes Signalisierungsprotokoll realisiert sein.
Um den speziellen Erfordernisse einer Verbindung im Transitnetz zu entsprechen, ist es sinnvoll, wenn im Rumpf einer von einem Teπninal an die Steuerstation gesendeten Request-Nachricht die Angabe erwünschter bzw. benötigter Verbindungsparameter zulässig ist. Die so übersendeten Verbindungsparameter können insbesondere einen oder mehrere der folgenden Kenngrößen betreffen: Verbindungstyp, Service-Kategorie, maximale Datenrate, Verwendungsfaktor, maximale Burst-Größe, gewünschte Priorität der Verbindung, Cell-Delay-Variation, rnaximaler Cell-Transf er-Delay . '' -
In einer bevorzugten Ausführungsform der Erfindung - insbesondere bei einem Satellitensystem - wird die Zuteilung von Bandbreiten zur Datenübertragung seitens des bzw. der Satelliten durch eine dynamische Ressourcenverwaltung in Abhängigkeit von den angefor- derten Verbindungsqualitäten gesteuert, um eine optimale Auslastung zu erreichen und die Verbindungsqualität zu verbessern. Hierbei kann die einem Satelliten zugeordnete Ressourcenverwaltung im Rahmen eines On-Board-Systems auf diesem Satelliten ablaufen.
Die Erfindung samt weiterer Vorzüge wird im Folgenden anhand eines nicht einschränkenden Ausführungsbeispieles näher erläutert, wobei die beigefügten Zeichnungen herangezogen werden. Die Zeichnungen zeigen in schematischer Form:
Fig. 1 ein SatelHtenkomrnunikationsnetz mit "On-Board Processing";
Fig. 2 den Aufbau einer Punkt-zu-Punkt-Verbindung im Netz der Fig. 1;
Fig. 3 den Abbau der Verbindung der Fig. 2;
Fig.4 den Aufbau einer Punkt-zu-Meh unkt-Verbindung;
Fig.5 den teilweise erfolgreichen Aufbau einer Punkt-zu-Mehrpunkt-Verbindung;
Fig. 6 die Erweiterung einer Punkt-zu-Mehrpunkt-Verbindung;
Fig. 7 den Abbau der Verbindung der Fig.4;
Fig. 8 ein EDN-Interworking anhand des Signalaustauschs der Fig. 2.
Die Erfindung kann für verschiedene Typen und Architekturen eines Transitnetzes eingesetzt werden. Dem Ausführungsbeispiel wird ein Satellitennetz SAN mit einem Breitband- Satellitensystem BSS der in der Bescihreibungseinleitung anhand Fig.1 dargestellten Art zu Grunde gelegt. Wie bereits erwähnt verfügt ein solches System BSS über einen geostationä- ren Satelliten SAT mit "On-Board Processing", eine zentrale Netzwerk-Steuerstation NCC, die eine Steuereinrichtung im Sinne der Erfindung darstellt, und eine Anzahl von (typischerweise mehreren tausend) Sateüitenterminals ST1, ST2, ST3, ST4, die in dem hier betrachteten Ausführungsbeispiel bodengestützt sind und mit unterschiedliφen Sende- und Empfangskapazitäten ausgestattet sein können.
Der Satellit SAT verfügt im Rahmen seines On-Board-Processing-Systems über eine eigene dynamische Ressourcenverwaltung. Diese ist für die tatsächliche Zuteilung von Bandbreite zum Übertragen von Daten zuständig. Bei einem erfolgreichen Verbindungsaufbau wird die Ressourcenverwaltung informiert, dass eine Verbindung mit bestimmter Verbindungsqualität zwischen den beteiligten Satej-ütenterminals besteht. Die Ressourcenverwaltung ist damit angewiesen, diesen Terminals (die in der Verbindungsqualität definierte) Bandbreite zum Übertragen von Daten zuzuweisen, wann immer die Terrninals Daten übertragen möchten. Die Zuweisung der Ressourcen auf dem Satelliten-Link erfolgt damit „dynamisch", also immer genau dann, wenn ein SatelHtenterminal diese Ressourcen benötigt. Während der Zeit, in der ein Sateffitenter inal keine Daten sendet, können diese Ressourcen für andere Verbindungen genutzt werden.
Die Erfindung verwendet als Ausgangspunkt den SIP-Standard gemäß lETF-Standard RFC 3261 („Standard-SIP"). Ausgehend von diesem Standard wird das Protokoll im Rahmen der hier beschriebenen Erfindung wird für den Einsatz in der beschriebenen Satellitenarchitektur optimiert. Dabei wird die Ähnlichkeit der Satellitenarchitektur mit einem SD?- Netzwerk mit Proxy-Server ausgenutzt: Ein SIP-Proxy-Server kann Verbindungen zwischen verschiedenen SEP-Endgeräten (z.B. SDP-Telefonen) herstellen. Die Aufgaben des Steuer- zentrurns NCC sind denen eines SEP-Proxy-Servers sehr ähnlich. Die Satel ienterminals ST1, ST2 entsprechen den SD?-Endgeräten im SD?-Netz. Das sich so ergebende modifizierte SD?- Protokoll kann somit als „Sat-SD?" bezeichnet werden.
Aufgrund der speziellen Architektur des hier zugrunde gelegten Satellitennetzes werden in Sat-SD? folgende Vereinfachungen vorgeschlagen:
1. Sat-SD? kommt mit wesentlich weniger Header-Feldern in den Nachrichten aus als Standard-SEP. Konkret sind in Sat-SD? nur folgende Header-Felder notwendig: accept, allow, error-info, from, to, cseq, call-id, expires und retry-after, sowie die drei Header-Felder für die Authentifizierung: WWW-Authenticate, Authorization und Authentication - Info.
2. Sat-SD? kommt mit wesentlich weniger Nachrichten als Standard SD? aus. Konkret sind in Sat-SD? nur folgende Nachrichten vorgesehen: ACK, BYE, CANCEL, INVITE, REGISTER, 100, 200, sowie 4xx und 5xx-Nachrichten. In Sat-SD? werden die gleichen Namen für die einzelnen Nachrichtentypen wie in Standard-SD? verwendet, jedoch könnten ebenso andere Bezeichner verwendet werden, ohne dass die Funktionalität des Protokolls beeinträchtigt würde.
Dagegen soll Sat-SD? folgende funktionale Erweiterungen im Vergleich zu Standard-SD? ermöglichen:
- Unterstützung von Punkt-zu-Mehrpunkt (ptmp, 'point to multiple point') Sitzungen. Bei einer pmtp Verbindung sind ein rufendes und mehrere angerufene Terminals eingebunden. Verfahren zum Aufbau und Abbau solcher Verbindungen sowie zum Hinzufügen oder Entfernen von Teilriehmern sind in Sat-SD? definiert. Diese Verfahren werden weiter unten näher beschrieben. Natürlich unterstützt das Sat-SD? Protokoll weiterhin (wie Standard-SD?) den Aufbau und Abbau von Punkt-zu-Punkt (ptp, 'point to poin ) Sitzungen, also zwischen einem rufenden und einem gerufenen Terminal. - Einsatz eines Verfahrens zur Zugangskontrolle für Verbindungen, nämlich des weiter unten erläuterten CAC, welches hier die Zulassung von Verbindungen im Satellitensystem SAN kontrolliert. In den Verbindungsaufbau- und -abbauprozessen sind entsprechende Stellen vorgesehen, wo ein solches Verfahren einzubauen ist. Es kann jedoch in Sat-SIP offen bleiben, welches konkrete Verfahren verwendet wird.
- Konfiguration eines Ressourcen-Steuerungssystems. In den Verbindungsaufbau- und -abbauprozessen sind entsprechende Stellen vorgesehen, wo eine solche Konfiguration einzubauen ist. Da verschiedenartige Ressourcen-Steuerungssysteme in verschiedenen Satellitensystemen eingesetzt werden können, lässt Sat-SD? offen, wie die Ansteuerung konkret funktioniert. Die Ressourcensteuerung kann in der Steuerstation NCC und/ oder on-board, also auf dem Satelliten, vorgesehen sein, wie dies z.B. vom EuroSkyWay- System her bekannt ist. Der Vorteil der letzteren Variante liegt darin, dass die Signallaufzeiten geringer sind und somit Ressourcen-Anforderungen rascher behandelt werden können, was den Nachteil der größeren Komplexität von On-Board-Systemen aufwiegen kann.
Für die Implementierung dieser Erweiterungen werden folgende Änderungen und Erweiterungen bei Nachrichten und Header-Feldern vorgeschlagen:
1. In der INVITE-Nachricht können neue Rumpffelder enthalten sein, die es erlauben, Parameter zur Beschreibung der Verbindungsqualität zu transportieren. Diese Rumpf felder ersetzen den SDP-Rumpf, der in Standard-SD? vorgesehen ist.
2. Im Header-Feld to, das zur Bezeichnung des gerufenen Endgeräts dient, können ein oder mehrere Terminals angegeben werden. Im Fall dass mehr als ein Terminal angegeben wird, wird eine ptmp Verbindung aufgebaut. (In Standard-SD? kann im Header-Feld to nur ein Endgerät spezifiziert werden. )
3. Ein weiteres Rumpffeld (namens „4xx Final Response", kurz 4FIN) wurde eingeführt, das speziell bei ptmp Verbindungen benötigt wird. Dieses Rumpffeld wird - sofern benötigt - in der 200-Nachricht verwendet.
4. Eine neue Nachricht (namens 499 „All Terminals Failed") speziell für ptmp Verbindungen wurde eingeführt. Diese Nachricht muss 4FIN Rumpf f eider enthalten.
Die unter Ziffer 1 genannten neuen Rumpffelder werden insbesondere dafür verwendet, dass ein Satelhtenterminal der Steuerstation NCC Charakteristika der angeforderten Verbindung übermitteln kann. Zur Beschreibung dieser Charakteristika sind nämlich andere Parameter notwendig als bei Verbindungen des Standard-SD? im SDP-Rumpf enthalten sind. Im Ausführungsbeispiel sind folgende Parameter zur Beschreibung der angeforderten Verbindungscharakteristik vorgesehen: Verbindungstyp (unidirektional oder bidirektional; ptp oder ptmp), Service-Kategorie, maximale Datenrate, Verwendungsfaktor (das Verhältnis zwischen durchschnittlicher und rnaximaler Datenrate), rnaximale Burst-Größe (maximale, auf einmal zu sendende Datenmenge), gewünschte Priorität der Verbindung, Cell-Delay- Nariation, maximaler Cell-Transfer-Delay. Bei bidirektionalen Verbindungen können alle Merkmale - ausgenommen den Verbindungstyp - für jede Verbindungsrichtung angegeben werden.
Die unter Ziffern 2 bis 4 genannten Erweiterungen beziehen sich auf ptmp Verbindungen, die weiter unten näher behandelt werden.
Mit Sat-SD? wird daher
- ein „Verbindungsbewusstsein" in den Sate tenter inals SU, ST2 und in der zentralen Steuerstation ΝCC hergestellt;
- dieses Verbindungsbewusstsein in Zusammenarbeit mit geeigneten Verfahren wie dem C AC für die Zulassung neuer Rufe ins System verwendet; und
- die Ressourcensteuerung des Satellitensystems entsprechend der neu hergestellten Verbindung konfiguriert Mit dieser Konfiguration ist eine Νutzdatenverbindung zwischen den Sate tenterminals hergestellt, sodass diese beginnen können, Νutzdaten über den Satellit zu übertragen.
In der Steuerstation ΝCC ist wie erwähnt ein Verfahren zur Zulassung von Verbindungen im Satellitennetz eingerichtet, das in dieser Offenbarung als CAC ('Connection Admission Control') bezeichnet wird. Das CAC ist typischerweise in Form eines Computerprograrnms realisiert, jedoch ist grundsätzlich auch eine Realisierung als Hardwareeinheit möglich. Das CAC entscheidet z.B. nach einem statistischen Algorithmus, ob aufgrund der aktuellen Systemauslastung eine angeforderte Verbindung zugelassen werden kann, ohne dadurch die Service-Qualität bereits bestehender Verbindungen einzuschränken oder zu gefährden. Fällt die Entscheidung positiv aus, wird die Verbindung aufgebaut. Anderenfalls wird der Verbindungsaufbau erfolglos abgebrochen. Ein Verfahren solcher Art ist beispielsweise in EP 1146763 A2 beschrieben, deren Inhalt als Teil dieser Offenbarung aufgenommen wird.
Das CAC ist vor allem im Hochlastbereich sehr vorteilhaft, setzt aber ein Verbindungsbewusstsein voraus. Es sei darauf hingewiesen, dass das CAC kein wesentliches Element der Erfindung ist. Vielmehr kann in einer vereinfachten Ausführungsform der Erfindung auf die Einbeziehung eines CAC verzichten werden, wenn der Vorteil einer garantierten Service- Qualität für akzeptierte Verbindungen nicht erforderlich ist.
Grundsätzlich kann das Sat-SD? Protokoll ebenso wie Standard-SD? ptp Sitzungen steuern. Wie bereits oben beschrieben, werden dazu im wesentlichen die im SD?-Standard definierten Nachrichten und Finite-State-Maschinen verwendet. Die wesentlichen Erweiterungen bestehen in der Berücksichtigung der Prozeduren für Qualitätssicherung (QoS, 'Quality of Service') und Ressourcen anagernent insofern, als bereits vom Sat-SD? Protokoll her die Voraussetzungen geschaffen werden, um diese Prozeduren in einem SateUitensystem effizient zu unterstützen. Aus der Sicht des im SDP-Standard definierten Protokolls sind QoS und Ressourcenmanagement durch andere Protokolle abzudecken, da für Standard SD? nur die Applikationssicht entscheidend ist
Eine bereits erwähnte, jedoch wesentliche Erweiterung gegenüber dem Standard SEP sind ptmp Sitzungen. Während das Standard SIP Protokoll Mehrpunkt-Sitzungen ('multicast sessions') und Konferenz-Sitzungen immer als mehrere ptp Sitzungen (z.B. über eine Konferenz-Bridge) aufbaut, kann in der Erfindung günstigerweise eine andere Lösung eingesetzt werden, die auch im Sat-SD? realisiert ist. Die Möglichkeit des pmtp ist wegen der Broadcast-Funktionalität des Satelliten sowie die zugrunde liegende Architektur sehr gut geeignet
Die Signalisierungsnachrichten werden vom Satelhtenterminal ST1 bzw. ST2 über einen eigenen Signalisierungskanal (in der Figur nicht dargestellt), den sogenannten RASC ('Random Access Channel'), über den Satelliten SAT (in Fig. 2 und 3 der Übersichtlichkeit halber nicht dargestellt) und zur Steuerstation NCC transportiert, bzw. von dort über den Satelliten an das betreffende SatelHtenterminal ST1 bzw. ST2. Der RASC ist ein nicht kollisionsfreier Kanal und kann z.B. unter Verwendung der bekannten ALOHA- oder slotted-ALOHA-Verfahren realisiert werden.
Im Steuerzentrum NCC wird aufgrund der übertragenen QoS- und Verkehrs-Parameter entschieden, ob die neue Verbindung im Komm.unikationsnetz zugelassen werden kann. Eine Zulassung erfolgt, wenn die QoS aller bereits im Netz bestehenden Verbindungen nicht beeinträchtigt wird. Verfahren dieser Art sind aus dem Stand der Technik wohlbekannt
Fig. 2 zeigt den Nachrichtenfluss für einen erfolgreichen ptp Rufaufbau in einem Signalablaufsdiagramm. In den Signalablaufsdiagrammen verläuft die Zeitachse vertikal nach unten, und die zwischen den verschiedenen, als vertikale Linien symbolisierten Stellen ausgetauschten Nachrichten sind als Pfeile dargestellt. Für die in den Signalablaufsdiagrammen ausgetauschten Nachrichten werden in dieser Offenbarung dreistellige Bezugszeibhen verwendet, wobei die zweite Ziffer das Satellitenterminal STn (π=l, ..., 4) bezeichnet, mit dem die Nachricht ausgetauscht wird, und die dritte Ziffer die Art der Nachricht angibt (z.B. bezeichnet eine letzte Ziffer 1 eine INVITE-Nachricht). Die in dem Vorgang der Fig.2 ausgetauschten Nachrichten pll-p24 sind außerdem in Tabelle 1 (im Anhang dieser Beschreibung) wiedergegeben. Für die in den Tabellen 1, 3 und 4 wiedergegebenen Nachrichten werden folgende Annahmen getroffen:
Die im Satellitensystem intern verwendete Kennung des NCC lautet NGGID.
Die im Satellitensystem intern verwendete Kennungen der Satel-titenterminals ST1, ST2, ST3 und ST4 lauten ST1 ID, ST2ID, ST3ID, ST4ID.
Im Body der ΓNVTTE Nachricht sind einige, nicht jedoch alle in Sat-SD? definierten QoS Parameter enthalten. In einer Implementierung werden abhängig vom konkreten Satellitensystem, dem verwendeten CAC und der Verbindungsart nur die benötigten QoS Parameter (alle oder wie hier nur ein Teil) im Body-Feld der DSTVi'lΕ Nachrichten transportiert. Weiters werden bei bi-direktionalen Verbindungen die QoS-Parameter für die Vorwärts- und Rückwärtsrichtung getrennt angegeben; bei uni-direktionalen Verbindungen werden nur die Parameter für die Vorwärtsrichtung angegeben. In jedem Fall müssen jedoch zwei Parameter, die den Verbindungstyp spezifizieren, angegeben werden: PTP (Punkt-zu-Punkfc "true" oder "false") und UNI (unidirektional: "true" oder "false").
Zur besseren Lesbarkeit wurden bei den Nachrichten jeweils die voUen Feldbezeichner verwendet. Sat-SD? sieht jedoch wie Standard-SD? vor, die Bezeichner häufig vorkommender Felder abzukürzen, damit die Nachrichten kürzer werden. Beispielsweise könnte anstatt "From :" ebenso "f :" oder statt "Call- ID" einfach "i :" in einer Nachricht stehen.
Der Aufbau einer ptp Sitzung wird, durch einen Request pll "INVITE" des (rufenden) SatelUtenterrninals ST1 eingeleitet Durch eine Rückwärtsnachricht pl2 "100" wird die erfolgreiche Ankunft der INVITE-Nachricht bestätigt. Seitens des NCC findet eine CAC- Prüfung statt; dies ist durch das Bezugszeichen Cl symbolisiert. Bei erfolgreichem CAC wird die Verbindung zugelassen, sowie Ressourcenmanagementprozeduren zur Belegung von Ressourcen auf den Übertragungsstrecken angestoßen und das gerufene Sate tenterminal ST2 durch eine INVITE-Nachricht p21 informiert Wenn das gerufene Terminal ST2 die Verbindung annehmen kann, antwortet es mit einer 200-Nachricht p23, die an das NCC zurückgesendet wird. Nach erfolgreicher Beendigung der Ressource-Zuweisung wird die 200-Nachricht p!3 an das rufende Terminal SU weiter geleitet, das seinerseits den Empfang durch eine ACK-Nachricht pl4 quittiert, die entsprechend als Nachricht p24 an das gerufene Terminal ST2 weiter geleitet wird. Damit ist der Rufaufbau abgeschlossen und die Satellitenterminals können mit der Übertragung der Nutzinformation sl2 beginnen. Die Zuteilung der Verbindungsstrecken erfolgt, je nach Implementation, z.B. nach erfolgreichem CAC parallel zum Senden der πsTVETE-Nachricht p21; es könnte hierfür jedoch auch die Bestätigung p23 abge artet werden. Im Gegensatz zu Standard-SD? erübrigt sich bei diesem Ablauf eine R I NGI NG-Nachricht
Zur Berücksichtigung der längeren Signallaufzeiten in Satellitennetzwerken werden die im Standard-SD? definierten Timer angepasst. Tabelle 2 zeigt ein Beispiel eines Satzes sinnvoller Werte für ein GEO-System nach Fig.1. Dem Wertesatz liegt die Annahme zugrunde, dass eine unzuverlässige Transportschicht wie UDP verwendet wird, weshalb auch die Werte für Retransmission angeführt sind. Selbstverständlich sind die gezeigten Werte in Abhängigkeit von der verwendeten Konfiguration (LEO, MEO, GEO, etc.) an das'jeweilige SateUitensystem anzupassen. In Tabelle 2 wird - über Standard-SD? hinaus - ein Zeitparameter satT verwendet, der im betrachteten Beispiel den Wert 500 ms hat Sollte eine zuverlässige Transportschicht verwendet werden, wie z.B. TCP, oder die Retransmission wird von der physikalischen Schicht des SatellitenprotokoU-Schichtenmodells übernommen, so können (entsprechend Standard-SD?) die Timer für die Konfiguration der Retransmission auf den Wert 0 gesetzt werden.
Die nicht erfolgreichen Fälle sowie die Möglichkeit der Annullierung eines Rufaufbauwun- sches verlaufen unter Berücksichtigung des oben Gesagten analog zu denen im SDP- Standard; eine Behandlung in dieser Offenbarung erübrigt sich daher.
Fig.3 zeigt den Nachrichtenfluss eines erfolgreichen ptp Rufabbau, z.B. des Abbaus der nach Fig.2 hergestellten Verbindung. Der Abbau wird durch eine BYE-Nachricht pl5, pl6 initiiert, die ebenfalls durch eine 200-Nachricht p26, pl6 quittiert wird. Der Vorgang entspricht den Vorgängen des Standard-SD?. Anschließend werden mittels eines CAC-Aufrufs C2 die im Steuerzentrum NCC belegten Ressourcen freigeschaltet bzw. die QoS-Parameter zurückgesetzt.
Fig.4 zeigt einen erfolgreichen Rufaufbau für einen ptmp Ruf. Anders als im Standard SD? werden für eine ptmp Sitzung nicht einzelne ptp Sitzungen zusammengeschaltet, sondern der ptmp Ruf wird im Steuerzentrum NCC insgesamt abgehandelt Die von dem rufenden Sateffitenterrninal ST1 an das Steuerzentrum NCC gesendete, den Rufaufbau einleitende INVITE-Nachricht mll enthält die Identifikationen und Parameter sämtlicher gerufener SatelHtenterrrrJxtals ST2, ST3, ST4, die zu der gewünschten ptmp Sitzung zusammengeschaltet werden sollen.
Der Ablauf des Ruf aufbaus zwischen dem rufenden Sateffitenterminal ST1 und dem Steuerzentrum NCC vollzieht sich gänzlich den Prozeduren des Standard-SD? entsprechend, wodurch die Finite-State Maschinen nicht angepasst werden mussten. Als weiterer Vorteil dieser Verfahrensweise ergibt sich, dass die Signalisierungslast am RASC mmimiert wird, wodurch auch die KolJisionswahrscheinlichkeit herabgesetzt wird. Dies ist ein wesentliches Erfordernis für Übertragungsstrecken in Satellitennetzen, wo die Ressourcen teuer und daher wertvoll sind. Zwischen dem Steuerzentrum NCC und den geru enen Satellitenterminals ST2, ST3, ST4 werden jeweils einzelne Sub-Sitzungen aufgebaut, die zu der gemeinsamen ptmp gehören und durch eine gemeinsame call - id-Nummer identifiziert werden.
Die gerufenen Sateffitenterminals antworten mit unterschiedlichen Rückwärtsnachrichten, je nachdem ob das betreffende SateUitenterminal an der ptmp Sitzung teilnehmen kann oder nicht Im Fall des erfolgreichen Ruf aufbaus konzentriert die Steuerstation NCC alle von den gerufenen Terminals kommenden Rü cwä^tsnachrichten (200 oder 4xx Nachrichten).
Der Aufbau der ptmp Sitzung (Fig.4) erfolgt somit ähnlich dem einer ptp Sitzung (Fig.2); zur Verdeutlichung werden für die in Fig. 4, 5 und 7 ausgetauschten Nachrichten Bezugszeichen der Form 3nm verwendet, die denen in Fig. 2 und 3 (der Form lnm) entsprechen. Tabelle 3 gibt die ausgetauschten Nachrichten der Fig. 4 und 5 wieder. Durch eine Rückwärtsnachricht ml2 "100" wird die erfolgreiche Ankunft der INVITE-Nachricht bestätigt. Seitens des NCC findet eine CAC-Prüfung C3 statt; ist diese erfolgreich, wird die Verbindung zugelassen und Ressourcenrnanagementprozeduren zur Belegung von Ressourcen auf den Übertragungsstrecken angestoßen; weiters werden die gerufenen Terminals ST2, ST3, ST4 durch INVITE-Nachrichten m21, m31, m41 informiert. Die gerufenen SatelHtenterminals antworten mit 200-Nachrichten m23, m33, m.43. Diese werden gebündelt in einer 200- Nachricht ml3 an das rufende SatelHtenterminal ST1 weiter geleitet Die quittierende ACK- Nachricht ml4 wird durch Nachrichten m24, m34, m44 an die gerufenen SatelHtenterminals weiter geleitet, woraufhin die SateUitenterminals mit der Übertragung der Nutzinformation s4 in der ptmp Sitzung beginnen können.
In Fig.5 ist der Fall berücksichtigt, dass eines der gerufenen Sate tenterrriinals - z.B. das Teririinal ST3 - die Teilnahrne an der ptmp Sitzung nicht annimmt Dieses Terrninal antwortet dann mit einer 486-Nachricht (Bezugszeichen m37), während die anderen Terminals, die den Ruf akzeptieren, mit 200 (Bezugszeichen m23, m24) antworten. In diesem FaH wird eine 200-Nachricht ml3' übertragen, die zusätzlich im Rumpf die Identifikation derjenigen Terminals enthält, die negativ quittiert haben. Für jede 4xx-Antwort eines eingeladenen SatelHtenterminals ST3 wird ein 4FIN-Rumpffeld (4FIN für '4xx Final Response') angehängt, das die Kennung des ablehnenden Satelu^enterrninals und den zugehörenden 4xx- Antworttyp enthält; die 200-Nachricht ml3' weist somit ein 4FIN-Rumpffeld mit der Information auf, dass das SatelHtenterminal ST3 mit 486 geantwortet hat. An der Schnittstelle zwischen dem Steuerstation NCC und dem rufenden SatelHtenterrriinal STl wird somit auch in diesem FaU nur eine 200-Nachricht ml3' übertragen, was die Finite-State-Maschine des rufenden SatelHtenteπrtinals vereinfacht und die Beibehaltung der standardgemäßen Maschine gestattet. Die so aufgebaute ptmp Sitzung s3 bezieht in diesem FaU dieses Sateffitenterminal ST3 nicht ein. Im Übrigen entspricht der Aufbau der Sitzung s3 nach Fig.5 dem Vorgang des erfolgreichen Aufbaus wie in Fig.4 beschrieben.
Falls - bezugnehmend auf Fig. 5a - aUe eingeladenen Terminals ST2, ST3, ST4 mit einer 4xκ- Nachricht m27, m37, m.47 antworten, wird ansteUe einer 200-Nachricht m!3' eine 499- Nachricht ml7 ersteUt Ebenso wie bei der Nachricht ml3" wird für jede 4xx-Antwort an die 499-Nachricht ml7 jeweils ein 4FIN-Rumpffeld angehängt (vgl. TabeUe 3).
Weiters können durch das erfindungsgemäße Sat-SD? Protokoll auch Prozeduren zur Einbeziehung zusätzHcher Teilnehmer - „ Add Party" - oder des Ausscheidens einzelner Teilnehmer - „Drop Party" - in Bezug auf eine ptmp Sitzung unterstützt werden. TabeUe 4 gibt die ausgetauschten Nachrichten der Fig. 6 und 7 wieder. Fig.6 zeigt ein Beispiel eines Add- Party-Vorgangs, beispielsweise das nachträgHche Einbeziehen des SatelHtenterminals ST3 im Anschluss an den Vorgang der Fig.5, sodass ausgehend von der Sitzung s3 eine Sitzung s4' erreicht wird, in die das Terminal ST3 ebenfalls eingebunden ist, entsprechend dem Ergebnis der Fig.4. Dieser FaU verläuft wie der Aufbau einer eigenen Sitzung (Fig.2), und die einzelnen Nachrichten sind mit Bezugzeichen bnm entsprechend den Nachrichten pnm der Fig.2 bezeichnet. Der Unterschied zu dem Vorgang der Fig.2 besteht darin, dass gegenüber den Parametern, die bei der HersteUung der ptmp-Verbindung nach Fig.5 in den Header- Feldern der Wert des Parameters cseq erhöht wird, um den Ablauf als eigene Transaktion zu kennzeichnen, während der Parameter callid gleich ist Wenn mehrere INVITE- Nachrichten innerhalb einer Sitzung verwendet werden, beispielsweise um mehrere SateUitentenninals zu einer ptmp-Sitzung einzuladen oder um - wie hier - ein SatelHtenterminal nachträgHch einzuladen, enthält jede INVITE-Nachricht die gleiche callid; um zwischen den einzelnen INVITE-Nachrichten unterscheiden zu können, erhalten sie verschiedene cseq-Werte. Dies entspricht dem Standard-SD?. Gleiches geschieht bei den BYE- Nachrichten, während in einer ACK oder CANCEL-Nachricht die gleiche cseq wie die jeweils zugehörende INVITE-Nachricht verwendet wird. Die ENfVITE-Nachricht bll weicht von der entsprechenden Nachricht pll insbesondere darin ab, dass sie einen leeren Nachrichtenrumpf hat
Fig. 7 zeigt den erfolgreichen Ruf abbau im ptmp FaU. Wiederum wird die gesamte Information über die zu benachrichtigenden SatelHtenterminals an das rufende Sateffitenterminal STl in einer gemeinsamen BYE-Nachricht ml5 übertragen, um einerseits den RASC-Kanal effektiv zu nützen und andererseits standardkonform zu bleiben. Zur Rückmeldung wird eine gemeinsame Quittierung ml6 verwendet. Im nicht erfolgreichen FaU wird wiederum der Rumpf der 200 Nachricht verwendet, um dem rufenden SatelHtenterminal STl diejenigen Teünehmer mitzuteüen, die eine negative Quittung geschickt haben. Auf Seiten der Sate tmterrrtinals ST2, ST3, ST4 ist der Vorgang gänzHch analog zu dem Vorgang der Fig.3; insbesondere entsprechen in Fig.5 die Nachrichten m25, m35, m45 (BYE) und m26, m36, m46 (200) den Nachrichten ρ25 bzw. ρ26 der Fig.3. Auch hier werden abschließend mittels eines CAC-Aufrufs C4 die im Steuerzentrum NCC belegten Ressourcen freigeschaltet bzw. die QoS-Parameter zurückgesetzt.
QoS- und/ oder Verkehrs-Parameter können für eine bestehende Sat-SIP-Sitzung neu verhandelt werden, indem diese Informationen in einer neuerHchen INVITE-Nachricht vom rufenden Terminal STl dem Steuerzentrum NCC mitgeteüt werden. Falls die neuen Parameter vom CAC akzeptiert werden, schickt das Steuerzentrum NCC entsprechende INVITE- Nachrichten an die gerufenen Terminals weiterleitet. Sobald aUe gerufenen Terminals mit einer 200 Nachricht geantwortet haben, schickt das Steuerzentrum NCC eine 200-Nachricht an das rufende SatelHtenterminal. Dieses antwortet mit einer ACK-Nachricht an das Steuerzentrum, welches wiederum eine ACK-Nachricht an jedes der gerufenen SatelHtenterminals schickt. Das Ändern von QoS- und/oder Verkehrs-Parametern kann nur das rufende Terminal veranlassen.
Der Sat-SD? CaU Control Prototyp wird weitgehend in SDL ('Specification and Description Language') geschrieben. Die Architektur des Sat-SD? CaU Control Prototypes, der das Sat-SD? ProtokoU implementiert, orientiert sich im wesentlichen an den vom SD? Standard geforderten funktionalen Einheiten. FolgHch sind die Terminal-Sat-SIP-Software und die Steuer- station-Sat-SD?-Software in Prozesse entsprechend Transaction User, CHent Transaction und Server Transaction unterteüt. CHent und Server Transactions sind in Standard-SD? beschrieben und vollständig sowie - mit Ausnahme der angepassten Timer - unverändert in Sat-SD? übernommen.
Darüber hinaus müssen gegebenenfalls für Koordinationszwecke (für die Steuerung der verschiedenen Prozessinstanzen) zusätzHche über den Standard hinausgehende Prozesse eingeführt werden. Der SIP-Standard beschreibt z.B. nur, dass bestimmte Aufgaben von bestimmten logischen Entitäten übernommen werden müssen, nicht jedoch, wie dies im konkreten FaU zu tun ist. Analoges gilt auch für die Software- Architektur des SatelHtenterminals.
Ein weiterer wichtiger Punkt ist die Frage des Zusammenwirken ('Interworking') von Sat- SIP mit bestehenden terrestrischen ProtokoUen und zwar verbindungsorientierten (ISDN, ATM) wie auch verbindungslosen ProtokoUen (EP). Hiezu ist eine eigene Interworking- Einheit im SateUitenterminal notwendig, die entweder aus einer im SatelHtenterrninal aus dem terrestrischen Netz ankommenden Nachricht (ISDN, ATM) oder aus einem ankommenden Packet (D?) einen Trigger für einen Verbindungswunsch ableitet, bzw. entsprechende Parameter aus der ankommenden Nachricht ableitet und eine geeignete Sat-SD? INVITE Nachricht absetzt. Gegebenenfalls muss auch das Mapping der Parameter auf die Sat-SIP Parameter in der Interworking-Einheit stattfinden (Abschluss der ankommenden Verbindung), oder die ankommenden Nachrichten werden über den aufgebauten Nutzkanal übertragen. Auf Besonderheiten des jeweüigen terrestrischen Protokolls (Timerverhalten, bei TCP/D? TCP SpHtting) muss dann individueU Rücksicht genommen werden.
Fig. 8 zeigt ein Beispiel eines Signalablaufs mit einem Interworking zwischen dem ISDN ProtokoU und dem Sat-SD? ProtokoU. Seitens einer dem rufenden SateUitenterminal STl zugeordneten jSDN- terwork g-Furtktion DF1 sei eine Q.931 SETUP-Nachricht ql empfangen worden. Die ankommende SETUP-Nachricht wird nun von der IWF „zurückgehalten", um zu prüfen, ob für den zu erwartenden (ISDN) Verkehr ein Verbindungswunsch akzeptiert werden kann; erst dann kann die SETUP-Nachricht an das gerufene Terminal ST2 bzw. dessen Interworking-Funktion D?2 weitergesendet werden. Die Interworking-Funktion D?l generiert somit aus der SETUP-Nachricht einen Setup-Request ipl (setup_req), der einen Anreiz zu Generierung einer INVITE Nachricht pll darsteUt. Der Setup-Request ipl enthält dabei aUe Informationen aus der angekommenen SETUP-Nachricht, die für die Generierung einer INVITE Nachricht pll notwendig sind (also im wesenfHchen die Verkehrs- und QoS Parameter). Innerhalb des SatelHtensystems folgen die Nachrichten pll, p21 usw. auf dieselbe Weise wie oben anhand der Fig.2 diskutiert wurde. Auf der gerufenen Seite ST2 wird dann beim Eintreffen der INVITE-Nachricht p21 eine Setup-Indikation pil (setup_ind) erzeugt, die an die Interworking-Funktion D72 des gerufenen SateUitenterminals ST2 geht. Der Empfang wird durch ein Setup-Response pi3 (setup_resp) quittiert. Diese enthält aUe Parameter, die zur Generierung der 200 Nachricht p23 notwendig sind, die dann über den SateUiten an das rufende SateUitenterminal STl als Nachricht ρl3 zurückgeschickt wird. Aus dieser wird im rufenden SatelHtenterminal STl eine Setup-Bestätigung ip3 (setup_cnf , 'setup confirrnation'), die ihrerseits wieder durch eine Nachricht ip4 (setup_cmp_req, 'setup completion request7) quittiert wird. Dies führt zum Aussenden einer ACK Nachricht pl4, p24, die die Transaktion im SatelHtensystem abschließt (Fig. 2). Auf der gerufenen Seite wird die ACK-Nachricht p24 wieder in eine Bestätigung ρi4 (setup_cmp_ind, 'setup complete indication') umgewandelt. Damit ist die Sat-SD? Sitzung sl2 und der zugehörige Nutzkanal über den SateUiten aufgebaut. Die in der rufenden Interworking-Funktion IF1 "wartende Q.931 SETUP-Nachricht q wird nun über einen dedizierten SignaHsierungskanal an das gerufene Sateffitenterminal ST2/IF2 übertragen (voUständige Trennung von SignaHsierungs- und Nutzinformation), und von dort an eine nachgeordnete ISDN-VermittlungssteUe weiter geleitet, die das Q.931 ProtokoU nach bekannter Art abarbeitet Der SignaHsierungskanal kann dabei permanent z.B. durch Konfiguration einem oder mehreren Satemtenter inals zugewiesen sein, oder er wird bei Bedarf aufgebaut, z.B. ebenfalls nach dem beschriebenen Verfahren. Die Signalisierungsin- formationen für ein bestimmtes SateUitenterminal durchlaufen somit einen "Single Hop". Zwischen den beiden Interworking-Funktionen EF1, EF2 läuft nun die standardkonforme ISDN Signalisierung ab, wobei der Informationsaustausch über die Sat-SD? Sitzung sl2 transparent abläuft.
Die SignaHsierung für den Rufabbau ergibt sich aus dem oben Gesagten in entsprechender Weise.
Die Erfindung ist freüich nicht auf das oben behandelte Beispiel des Sat-SD? eingeschränkt, vielmehr kann sie auch in aUgemeineren Systemen eingesetzt werden. So ist die Erfindung z.B. auch mit einem Schmalband-SateUitensystemverwendbar. Die Ressourcensteuerung des SateUiten SAT kann on-board oder in der Steuerstation NCC lokalisiert sein. Außerdem muss die Steuerstation NCC nicht als vom SateUiten getrennte terrestrische SteUe realisiert sein, sondern kann zur Gänze oder teüweise on-board sein. Auch kann ein Kommunikati- ons-SatelHtensystem ohne "On Board Processing" verwendet werden. In diesem FaUe läuft die Datenverbindung im "Double-Hop" vom rufenden Sate tenterminal über eine zentrale Bodenstation zum gerufenen SatelHtenterminal.
Auch können die Verbindungen unter Einbeziehung terrestrischer Netzwerk-Verbindungen (ohne SateUit) ersteUt werden, die ebenfalls gemäß der Erfindung, z.B. über Sat-SD?, signaH- siert werden.
TabeUe 1: Sat-SEP-Nachrichten der Fig.2 und 3 (ptp)
pll: STl -_> NCC
INVITE satsip:NCCID Sat-SIP/1.0 To: "Terminal ST2" <satsip:ST2ID> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 324&ST1ID CSeq: 1 INVITE
PTP=true,UNI=true3FUF=903FPDR=256
pl2: NCC -» STl
Sat-SIP/1.0 100 Trying
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 324@ST1ID
CSeq: 1 INVITE
p21: NCC -» ST2
INVITE satsip:ST2ID Sat-SIP/1.0 To: "Terminal ST2" <satsip:ST2ID> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 324&ST1ID CSeq: 1 INVITE
PTP=true , UNI=true , FUF=90 , FPDR=256
p23: ST2 -» NCC
Sat-SIP/1.0200 OK
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 324&ST1ID
CSeq: 1 INVITE
pl3: NCC - STl
Sat-SIP/1.0200 OK
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 324@ST1ID 1-
CSeq: 1 INVITE pl4: STl -» NCC
ACK satsip:NCCID Sat-SIP/1.0
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 324@ST1ID
CSeq: 1 ACK
p24: NCC -> ST2
ACK satsip:ST2ID Sat-SIP/1.0
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 324@ST1ID
CSeq: 1 ACK
P15: STl -> NCC
BYE satsip:NCCID Sat-SIP/1.0
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 324@STHD
CSeq: 1 BYE
p25: NCC - ST2
BYE satsip:ST2ID Sat-SIP/1.0
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 324@ST1ID
CSeq: 1 BYE
p26:ST2-»NCC
Sat-SIP/1.0200 OK
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 3240ST1ID
CSeq: 1 BYE
pl6: NCC • STl
Sat-SIP/1.0200 OK
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID> 1 _
Call-ID: 324@ST1ΪD
CSeq: 1 BYE TabeUe 2: Timer- Werte für Sat-SIP (beispielhafte Werte für Konfiguration der Fig. 1)
TabeUe 3: Sat-SIP-Nachrichten der Fig.4 und 5 (ptmp)
mll: STl ■» NCC
INVITE satsip:NCCID Sat-SIP/1.0
To: "Terminal ST2" <satsip:ST2ID>, "Terminal ST3" <satsip:ST3ID>,
"Terminal ST4" <satsip:ST4ID> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 325 ST1ID CSeq: 1 INVITE
PTP=false,UNI=trueJFUF=100,FPDR=512
ml2: NCC - STl
Sat-SIP/1 .0 100 Trying
To: "Terminal ST2" <satsip:ST2ID>, "Terminal ST3" <satsip:ST3ID>,
"Terminal ST4" <satsip :ST4ID> From: "Terminal ST1 " <satsip:ST1 ID> Call-ID: 325@ST1 ID CSeq: 1 INVITE
m21: NCC -> ST2
INVITE satsip:ST2ID Sat-SIP/1 .0 To: "Terminal ST2" <satsip:ST2ID> From: "Terminal ST1 " <satsip:ST1 ID> Call-ID: 325@ST1 ID CSeq: 1 INVITE
PTP=false,UNI=true, FUF=100J FPDR=512
m31: NCC -» ST3
INVITE satsip:ST3ID Sat-SIP/1.0 To: "Terminal ST3" <satsip:ST3ID> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 3250ST1ID CSeq: 1 INVITE
PTP=false,UNI=true,FUF=100,FPDR=512 m41: NCC ■* ST4
INVITE satsip:ST2ID Sat-SIP/1 .0 To: "Terminal ST4" <satsip:ST4ID> From: "Terminal ST1 " <satsip:ST1 ID> Call- ID: 325PST1 ID CSeq : 1 INVITE
PTP=f alse , UNI=t rue , FUF=100 , FPDR=512
m23: ST2 - NCC
Sat-SIP/1.0 200 OK
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 325@ST1ID
CSeq: 1 INVITE
m33: ST3 ■ NCC
Sat-SIP/1.0200 OK
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 325@ST1ID
CSeq: 1 INVITE
m43: ST4 ■» NCC
Sat-SIP/1.0200 OK
To: "Terminal ST4" <satsip:ST4ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 325§ST1ID
CSeq: 1 INVITE
ml3: NCC -» STl
Sat-SIP/1.0 200 OK
To: "Terminal ST2" <satsip:ST2ID>, "Terminal ST3" <satsip:ST3ID>, "Terminal ST4" <satsip:ST4lD> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 325@ST1ID CSeq: 1 INVITE ml4: STl -> NCC
ACK satsip: NCCID Sat-SIP/1 .0
To: "Terminal ST2" <satsip:ST2ID>, "Terminal ST3" <satsip:ST3ID>,
"Terminal ST4" <satsip:ST4lD> From : "Terminal ST1 " <satsip:ST1 ID> Call-ID: 325@ST1 ID CSeq : 1 ACK
m24: NCC -=> ST2
ACK satsip:ST2ID Sat-SIP/1.0
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 325 ST1ID
CSeq: 1 ACK
m34:NCC-»ST3
ACK satsip:ST3ID Sat-SIP/1.0
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 325@ST1ID
CSeq: 1 ACK
m44: NCC -» ST4
ACK satsip:ST4ID Sat-SIP/1.0
To: "Terminal ST4" <satsip:ST4ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 325@ST1ID
CSeq: 1 ACK
mll: STl •> NCC
INVITE satsip:NCCID Sat-SIP/1.0
To: "Terminal ST2" <satsip:ST2ID>, "Terminal ST3" <satsip:ST3ID>3
"Terminal ST4" <satsip:ST4lD> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 326@ST1ID CSeq: 1 INVITE
PTP=false,UNI=trueJFUF=1005FPDR=512 ml2: NCC -» STl
Sat-SlP/1.0 100 Trying
To: "Terminal ST2" <satsip:ST2ID>, "Terminal ST3" <satsip:ST3ID>,
"Terminal ST4" <satsip:ST4ID> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 326@ST1ID CSeq: 1 INVITE
m21: NCC -> ST2
INVITE satsip:ST2ID Sat-SIP/1.0 To: "Terminal ST2" <satsip:ST2ID> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 326@ST1ID CSeq: 1 INVITE
PTP=falseJUNI=trueJFUF=100,FPDR=512
m31: NCC -> ST3
INVITE satsip:ST3ID Sat-SIP/1.0 To: "Terminal ST3" <satsip:ST3ID> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 326@ST1ID CSeq: 1 INVITE
PTP=false,UNI=true,FUF=100,FPDR=512
m41: NCC ■ ST4
INVITE satsip:ST2ID Sat-SIP/1.0 To: "Terminal ST4" <satsip:ST4ID> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 326@ST1ID CSeq: 1 INVITE
PTP=false, UNI=true, FUF=100, FPDR=512
m23: ST2 - NCC
Sat-SIP/1.0 200 OK
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 INVITE m43: ST4 - NCC
Sat-SIP/1.0 200 OK
To: "Terminal ST4" <satsip:ST4ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 INVITE
m37: ST3 -> NCC
Sat-SIP/1.0 486 Busy Here
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 INVITE
Errorinfo: Busy Here
Retryafter: 10
ml3':NCC-»STl
Sat-SIP/1.0200 OK
To: "Terminal ST2" <satsip:ST2ID>, "Terminal ST4" <satsip:ST4ID>
Frόm: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 INVITE
4FIN:SatSIP/1.0486 Busy Here To: "Terminal ST3" <satsip:ST3ID> Error-Info: "Busy Here" Retryafter: 10
ml4: STl -> NCC
ACK satsip:NCCID Sat-SIP/1.0
To: "Terminal ST2" <satsip:ST2ID>, "Terminal ST3" <satsip:ST3ID>,
"Terminal ST4" <satsip:ST4ID> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 3260ST1ID CSeq: 1 ACK
m24: NCC -> ST2
ACK satsip:ST2ID Sat-SIP/1.0
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 ACK m34: NCC -» ST3
ACK satsip:ST3ID Sat-SIP/1.0
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 32β@ST1ID
CSeq: 1 ACK
m44: NCC ■» ST4
ACK satsip:ST4ID Sat-SIP/1.0
To: "Terminal ST4" <satsip:ST4ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 ACK
m27: ST2 -» NCC
Sat-SIP/1.0 486 Busy Here
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 INVITE
Errorinfo: Busy Here
Retryafter: 10
m37: ST3 -> NCC
Sat-SlP/1.0 486 Busy Here
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 INVITE
Errorinfo: Busy Here
Retryafter: 10
m47:ST4- NCC
Sat-SIP/1.0 486 Busy Here
To: "Terminal ST4" <satsip:ST4ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 INVITE
Errorinfo: Busy Here
Retryafter: 10 ml7: NCC -» STl
SatSIP/1.0499 "All Terminals failed"
To: "Terminal ST2" <satsip:ST2ID>, "Terminal ST3" <satsip:ST3ID>,
"Terminal ST4" <satsip:ST4lD> From: "Terminal ST1" <satsip:ST1ID> Call-ID:326@ST1ID CSeq: 1 INVITE
4FIN:SatSIP/1.0486 Busy Here To: "Terminal ST2M <satsip:ST2ID> Error-Info: "Busy Here" Retryafter: 10
4FIN:SatSIP/1.0486 Busy Here To: "Terminal ST3" <satsip:ST3ID> Error-Info: "Busy Here" Retryafter: 10
4FIN:SatSIP/1.0 486 Busy Here To: "Terminal ST4" <satsip:ST4ID> Error-Info: "Busy Here" Retryafter: 10
TabeUe 4: Sat-SDP-Nachrichten der Fig. 6 und 7 (Ädd-Partv, Prop-Partv)
bll: STl -» NCC
INVITE satsip-. NCCID Sat-SIP/1 .0 To: "Terminal ST3" <satsip: ST3ID> From: "Terminal ST1 " <satsip:ST1 ID> Call-ID: 326§ST1 ID CSeq : 2 INVITE
b!2: NCC -» STl
Sat-SIP/1 .0 100 Trying
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1 " <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq : 2 INVITE
b21: NCC ■ ST3
INVITE satsip:ST3ID Sat-SIP/1 .0 To: "Terminal ST3" <satsip:ST3ID> From: "Terminal ST1 " <satsip:ST1 ID> Call- ID: 3260ST1ID CSeq: 2 INVITE
PTP=f alse , UNI=t rue , FUF=100 , FPDR=512
b23: ST3 -> NCC
Sat-SIP/1.0200 OK
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 2 INVITE
bl3: NCC -» STl
Sat-SIP/1.0200 OK
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326<asτiID
CSeq: 2 INVITE bl4: STl ■» NCC
ACK satsip:NCCID Sat-SIP/1.0
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 2 ACK
b24: NCC -» ST3
ACK satsip:ST3ID Sat-SIP/1.0
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 2 ACK
Nachrichten der Fig. 7:
ml5: STl -> NCC
BYE satsip:NCCID Sat-SIP/1 .0
To: "Terminal ST2" <satsip:ST2ID>, "Terminal ST3" <satsip:ST3ID>,
"Terminal ST4" <satsip:ST4ID> From: "Terminal ST1 " <satsip:ST1 ID> Call-ID: 326§ST1 ID CSeq : 1 BYE
m25: NCC -> ST2
BYE satsip:ST2ID Sat-SIP/1.0
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 BYE
m35:NCC-»ST2
BYE satsip:ST3ID Sat-SIP/1.0
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 3260ST1ID
CSeq: 1 BYE m45: NCC - ST2
BYE satsip:ST4ID Sat-SIP/1.0
To: "Terminal ST4" <satsip:ST4ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 BYE
m26: ST2 ■» NCC
Sat-SIP/1.0 200 OK
To: "Terminal ST2" <satsip:ST2ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 BYE
m36: ST3 -» NCC
Sat-SIP/ 1.0 200 OK
To: "Terminal ST3" <satsip:ST3ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 326@ST1ID
CSeq: 1 BYE
m46:ST2^NCC
Sat-SIP/ 1.0200 OK
To: "Terminal ST4" <satsip:ST4ID>
From: "Terminal ST1" <satsip:ST1ID>
Call-ID: 3260ST1ID
CSeq: 1 BYE
ml6:NCC->STl
Sat-SIP/1.0 200 OK
To: "Terminal ST2" <satsip:ST2ID>, "Terminal ST3" <satsip:ST3ID>,
"Terminal ST4" <satsip:ST4ID> From: "Terminal ST1" <satsip:ST1ID> Call-ID: 326@ST1ID CSeq: 1 BYE

Claims

PATENTANSPRÜCHE
1. Verfahren zum Steuern von Verbindungen, insbesondere zum Verbindungsaufbau und/ oder -abbau, zwischen Transitnetz-Terminals (STl, ST2, ST3, ST4) eines Transitnetzes (BSS) mit einer zentralen Steuereinrichtung (NCC), einer Anzahl von Trartsitnetz-Terminals sowie gegebenenfalls einer oder mehreren, dem Transitnetz internen RelaissteUen (SAT), unter Verwendung von Transitnetz-Kommunikationsstrecken (seil, scl2), die jeweils zwischen zwei der Terminals und/ oder RelaissteUen verlaufen, wobei die Steuerung der Kommunikationsstrecken, insbesondere das Belegen und Freigeben derselben für Verbindungen zwischen Terminals, von der Steuereinrichtung (NCC) aufgrund von Signalisie- rungsinformation (ssg) durchgeführt wird, die zwischen der Steuerstation (NCC) und den Terminals ausgetauscht wird, dadurch gekennzeichnet, dass für den Austausch der SignaUsierungsinformation (ssg) ein SignalisierungsprotokoU verwendet wird, mit zumindest folgenden, dem SIP-Standard entsprechenden Request-
Nachrichtentypen:
- ein Nachrichtentyp QNVITE; pll, mll, bll) zum Einleiten eines Verbindungsaufbaus, ein Nachrichtentyp (BYE; pl5, m.15) zum Einleiten eines Verbindungsabbaus, und ein Nachrichtentyp (ACK; pl4, ml4, bl4) zum Bestätigen eines vorangegangenen Aus- tauschs von Signalisierungsinformation, sowie zumindest einem dem SD?-Standard entsprechenden Response-Nachrichtentyp (100,
200, 4xx; pl2, ml2, pl3, pl6, ml3, bl3, ml6, m37) für Bestätigungsmeldungen und/oder
Fehlermeldungen.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass in zumindest einem Teü der nach dem SignalisierungsprotokoU ausgetauschten Nachrichten, insbesondere Nachrichten (mll) nach dem Nachrichtentyp zum Einleiten eines Verbindungsaufbaus, mehrere gerufene Transif^etz-Terrninals (ST2, ST3, ST4) genannt werden, wobei solche Nachrichten für die Steuerung von Purikt-zu-Mehrpunkt-Verbindungen verwendet werden.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass ein zusätzHcher Response- Nachrichtentyp (499) verwendet wird, mit dem eine Fehlermeldung in Bezug auf sämtliche gerufenen Transitnetz-Terminals einer Punkt-zu-Mehrpunkt-Verbindung signalisiert wird.
4. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass in den Bestätigungsmeldungen (m!3') für Purtkt-zu-Merirpunkt-Verbindungen, zumindest jedoch in einem Teü von diesen, Rumpffelder nach einem zusätzHchen Rumpffeld-Typ (4FDNT) verwendet werden, wobei mittels jedes solchen Rumpffelds eine Fehlermeldung in Bezug auf ein gerufenes Transimetz-Terminal der betreffenden Punkt-zu-Mehrpunkt-Verbindung signalisiert wird.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das SignalisierungsprotokoU als auf dem D?-ProtokoU und/ oder einem diesen übergeordneten ProtokoU, wie TCP oder UDP, aufsetzendes SignalisierungsprotokoU reaUsiert ist.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass im Rumpf einer von einem Transitnetz-Terminal an die Steuereinrichtung gesendeten Request- Nachricht erwünschte bzw. benötigte Verbindungsparameter angegeben werden.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass zurriindest ein TeÜ der so übersendeten Verbindungsparameter einen oder mehrere der folgenden Kenngrößen betreffen: Verbindungstyp, ServicerKategorie, maximale Datenrate, Verwendungsfaktor, maximale Burst-Größe, gewünschte Priorität der Verbindung, CeU-Delay-Variation, maxima¬ ler CeU-Transf er-Delay.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass es zum Steuern von Verbindungen zwischen Satemtenterminals (STl, ST2, ST3, ST4) eines SateUiten- Telekommunikationssystems (BSS) mit einer zentralen Steuereinrichtung (NCC), einer Anzahl von Satemtenterrninals und zumindest einem SateUiten (SAT) verwendet wird, unter Verwendung von Kornmunikationsstrecken (seil, scl2), die jeweils zwischen zwei der SateUitenterminals und/oder SateUiten verlaufen, wobei die Steuerung der Kornmunika¬ tionsstrecken, insbesondere das Belegen und Freigeben derselben für Verbindungen zwischen Sate tenterminals, von der Steuereinrichtung (NCC) aufgrund von Signalisierungsinformation (ssg) durchgeführt wird, die zwischen der Steuerstation (NCC) und den SateUitenterminals ausgetauscht wird.
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Zuteüung von Bandbreiten zur Datenübertragung seitens des bzw. der SateUiten (SAT) durch eine dynami¬ sche Ressourcenverwaltung in Abhängigkeit von den angeforderten VerbindungsquaHtäten gesteuert wird. -
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die einem SateUiten (SAT) zugeordnete Ressourcenverwaltung im Rahmen eines On-Board-Systems auf diesem SateUiten abläuft.
- So ¬
ll . Steuereinrichtung (NCC) zur Steuerung, insbesondere zum Belegen und Freigeben, von Transimetz-Kommunikationsstrecken (seil, scl2) in einem Transitnetz (BSS) mit einer Anzahl von Trarisitnetz-Terminals sowie gegebenenfalls einer oder mehreren, dem Transitnetz internen RelaissteUen (SAT), wobei die Kommunikationsstrecken (seil, sc!2) jeweils zwischen zwei der Terminals und/ oder RelaissteUen verlaufen, wobei die Steuereinrichtung (NCC) zum Austausch von Signalisierungsinformation (ssg) mit den Terminals und zur Verarbeitung der Signalisierungsinformation (ssg) zur entsprechenden Steuerung der Kommunikationsstrecken für die Zwecke des Steuerns von Verbindungen, insbesondere des Verbindungsauf baus und -abbaus, zwischen den Terminals (STl, ST2, ST3, ST4) eingerichtet ist, dadurch gekennzeichnet, dass sie zur Verwendung eines SignaUsierungsprotokoUs für den Austausch der Signalisierungsinformation (ssg) eingerichtet ist, mit zumindest folgenden, dem SIP-Standard entsprechenden Request-Nachrichtentypen:
- ein Nachrichtentyp (TNVπΕ; pll, mll, bll) zum Einleiten eines Verbindungsauf baus, ein Nachrichtentyp (BYE; pl5, ml5) zum Einleiten eines Verbindungsabbaus, und ein Nachrichtentyp (ACK; pl4, ml4, bl4) zum Bestätigen eines vorangegangenen Aus- tauschs von Signalisierungsinformation, sowie zumindest einem dem SIP-Standard entsprechenden Response-Nachrichtentyp (100, 200, 4xx; pl2, ml2, pl3, pl6, ml3, bl3, ml6, m37) für Bestätigungsmeldungen und/ oder Fehlermeldungen.
12. Einrichtung nach Anspruch 11, dadurch gekennzeichnet, dass sie als Steuereinrichtung (NCC) für ein SateUiten-Telekommunikationssystem (BSS) mit einer Anzahl SateUitenterminals und zumindest einem SateUiten, eingerichtet ist, närrdich zur Steuerung, insbesondere zum Belegen und Freigeben, von SateUiten-Kommunikationsstrecken (seil, scl2), die jeweils zwischen zwei der SateUitenterminals und/ oder SateUiten verlaufen.
13. Termmal-Einrichtung (STl, ST2, ST3, ST4) für ein Transitnetz (BSS) mit einer zentralen Steuereinrichtung (NCC), für den Verbindungsauf- und -abbau in dem Transitnetz (BSS) in Zusammenwirken mit anderen Trarisitnetz-Terminals sowie gegebenenfalls einer oder mehreren, dem Transitnetz internen RelaissteUen (SAT) unter Verwendung von Kommunikationsstrecken (seil, scl2), die jeweils zwischen der Terminal-Einrichtung und einem anderen Terrninal oder einer RelaissteUe verlaufen, wobei die Term al-Einrichtung zum Austausch von Signalisieru gsinformation (ssg) mit der Steuereinrichtung (NCC) zur Steuerung der Kommunikationsstrecken, insbesondere das Belegen und Freigeben derselben für Verbindungen, eingerichtet ist, dadurch gekennzeichnet, dass sie zur Verwendung eines SignaMsierungsprotokoUs für den Austausch der Signalisierungs¬ information (ssg) eingerichtet ist, mit zumindest folgenden, dem SIP-Standard entsprechen¬ den Request-Nachrichtentypen:
- ein Nachrichtentyp (INVTTE; pll, mll, bll) zum Einleiten eines Verbindungsaufbaus, ein Nachrichtentyp (BYE; ρl5, ml5) zum Einleiten eines Verbindungsabbaus, und
- ein Nachrichtentyp (ACK; p!4, ml4, b!4) zum Bestätigen eines vorangegangenen Aus- tauschs von Signalisierungsinformation, sowie zumindest einem dem SIP-Standard entsprechenden Response-Nachrichtentyp (100, 200, 4xx; pl2, ml2, pl3, pl6, ml3, bl3, ml6, m37) für Bestätigungsmeldungen und/oder Fehlermeldungen.
14. Einrichtung nach Anspruch 13, dadurch gekennzeichnet, dass sie als. SateUitentermi- nal-Einrichtung (STl, ST2, ST3, ST4) für ein Satemten-Telekommunikationssystem (BSS) mit einer Anzahl Satewtenter inals und zumindest einem SateUiten, eingerichtet ist, närruich für den Verbindungsauf- und -abbau in einem SateUiten-Telekommunikationssystem (BSS) in Zusammenwirken mit zumindest einem SateUiten (SAT) unter Verwendung von SateUiten- Kommunikationsstrecken (seil, scl2), die jeweils zwischen dem Sateffitenterminal und dem zumindest einen SateUiten verlauf en.
15. Einrichtung nach einem der Ansprüche 11 bis 14, dadurch gekennzeichnet, dass in den nach dem SignalisierungsprotokoU ausgetauschten Nachrichten, insbesondere Nachrich¬ ten (mll) nach dem Nachrichtentyp zum Einleiten eines Verbindungsauf baus, die Nennung mehrerer gerufenen Terminals (ST2, ST3, ST4) zulässig ist, wobei solche Nachrichten für die Steuerung von Punkt-zu-Mehrpunkt-Verbindungen verwendet werden.
16. Einrichtung nach Anspruch 15, dadurch gekennzeichnet, dass ein zusätzUcher Response-Nachrichtentyp (499) zum Signalisieren einer Fehlermeldung in Bezug auf sämt- Uche gerufenen Terminals einer Punkt-zu-MehrpunktNerbindung vorgesehen ist.
17. Einrichtung nach Anspruch 15 oder 16, dadurch gekennzeichnet, dass in den Bestäti¬ gungsmeldungen (ml3') für Punkt-zu-Mehrpunkt-Verbindungen Rumpffelder nach einem zusätzUchen Rumpffeld-Typ (4FIN) zulässig sind, wobei mittels jedes solchen Rumpffelds eine Fehlermeldung in Bezug auf ein gerufenes Terminal der betreffenden Punkt-zu- Mehrpunkt-Verbindung signalisiert wird.
18. Einrichtung nach einem der Ansprüche 11 bis 17, dadurch gekennzeichnet, dass das SignalisierungsprotokoU als auf dem D?-ProtokoU und/ oder einem diesen übergeordneten ProtokoU, wie TCP oder UDP, aufsetzendes SignalisierungsprotokoU realisiert ist.
19. Einrichtung nach einem der Ansprüche 11 bis 18, dadurch ge ennse hnet, dass im, Rumpf einer von einem Terminal an die Steuereiririchtung gesendeten Request-Nachricht die Angabe erwünschter bzw. benötigter Verbindungsparameter zulässig ist.
20. Einrichtung nach Anspruch 19, dadurch gekennzeichnet, dass zumindest ein Teü der so übersendeten Verbindungsparameter einen oder mehrere der folgenden Kenngrößen betreffen: Verbindungstyp, Service-Kategorie, maximale Datenrate, Verwendungsfaktor, maximale Burst-Größe, gewünschte Priorität der Verbindung, CeU-Dela - Variation, maximaler CeU-Transfer-Delay.
EP04739095A 2003-04-29 2004-04-21 Verbindungssteuerung in einem transit-telekommunikationsnetz Withdrawn EP1618721A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AT0065803A AT412378B (de) 2003-04-29 2003-04-29 Verbindungssteuerung in einem transit-telekommunikationsnetz
PCT/EP2004/004213 WO2004098146A2 (de) 2003-04-29 2004-04-21 Verbindungssteuerung in einem transit-telekommunikationsnetz

Publications (1)

Publication Number Publication Date
EP1618721A2 true EP1618721A2 (de) 2006-01-25

Family

ID=32398599

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04739095A Withdrawn EP1618721A2 (de) 2003-04-29 2004-04-21 Verbindungssteuerung in einem transit-telekommunikationsnetz

Country Status (5)

Country Link
EP (1) EP1618721A2 (de)
AT (1) AT412378B (de)
CA (1) CA2524014C (de)
NO (1) NO20055529L (de)
WO (1) WO2004098146A2 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101815094A (zh) * 2010-03-18 2010-08-25 中兴通讯股份有限公司 一种实现数据共享访问的方法、装置及系统
US8935413B2 (en) * 2010-10-26 2015-01-13 Alcatel Lucent Delivery report for text messages in SIP communications

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6678264B1 (en) * 1999-06-30 2004-01-13 Nortel Networks Limited Establishing connections with a pre-specified quality of service across a communication network
US7136387B2 (en) * 1999-08-09 2006-11-14 Mci, Llc Method of and system for providing quality of service in IP telephony
US6577622B1 (en) * 1999-09-27 2003-06-10 3Com Corp. System and method for using a portable information device to establish a conference call on a telephony network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2004098146A3 *

Also Published As

Publication number Publication date
WO2004098146A3 (de) 2005-01-20
AT412378B (de) 2005-01-25
ATA6582003A (de) 2004-06-15
CA2524014C (en) 2012-10-30
CA2524014A1 (en) 2004-11-11
NO20055529L (no) 2005-11-23
WO2004098146A2 (de) 2004-11-11

Similar Documents

Publication Publication Date Title
DE69833111T2 (de) Bestimmung von trägerdiensten in einem funkzugriffsnetz
DE60131058T2 (de) Endgerät und Mediakommunikationssystem
DE69615225T2 (de) Verteilte architektur für dienste eines telefonsystems
DE69325203T2 (de) Verfahren und Vorrichtung für das gemeinsame Nutzen eines Telekommunikationskanals
DE19742681A1 (de) GPRS-Teilnehmerauswahl von mehreren Internet-Dienstanbietern
DE10005282A1 (de) Leitungsvermitteltes Privatkommunikationsnetz mit integrierten Paketvermittelten Multimedia-Nebenstellen
DE102005016587B4 (de) Verfahren zum Bilden einer gemeinsamen Kommunikationssitzung, Verfahren zum Bilden einer ersten Kommunikationssitzung und einer zweiten Kommunikationssitzung aus einer gemeinsamen Kommunikationssitzung und Kommunikationssitzungs-Steuerungs-Server
DE10085104B4 (de) Verfahren und Anordnung in einem Telekommunikationssystem
EP2469885B1 (de) Verfahren zur Integration von Funktionen eines Telekommunikationsnetzes in ein Datennetz
DE102004063298B4 (de) Verfahren zum rechnergestützten Verwalten von Kommunikationsrechten zum Kommunizieren mittels mehrerer unterschiedlicher Kommunikationsmedien in einer Telekommunikations-Konferenz mit mehreren Telekommunikations-Einrichtungen
DE102004010925B9 (de) Verfahren und Kommunikationsanordnung zum Aufbauen einer Push-to-talk-Kommunikationsverbindung und Push-to-talk-Client-Einheit
DE102008054143B4 (de) Abwicklung eines auf Halten geschalteten Session-Initiation-Protocol-fähigen Telekommunikations-Endgeräts
EP1665756A1 (de) Interworking von protokollen hybrider multimedianetze
EP1482701B1 (de) Verfahren zum paketorientierten Übertragen von Daten in Telekommunikationsnetzen mittels Umsetzung in einem Zwischenknoten von einem verbindungslosen zu einem verbindungsorientierten Übertragungsprotokoll und umgekehrt
EP1505842B1 (de) Verfahren zum Umsteuern einer Bearerverbindung (Bearer Redirect) für SIP/ SIP-T Teilnehmer
DE102006027708B3 (de) Verfahren zur Optimierung einer Kommunikationsverbindung in einem paketvermittelten Sprachdatennetzwerk
EP1618721A2 (de) Verbindungssteuerung in einem transit-telekommunikationsnetz
EP1308006B1 (de) Verfahren zum aufbau einer verbindung mit vorgegebener dienstgüte zwischen kommunikationsnetzen mit resourcenmanagern
EP1761081A1 (de) Kommunikationssystem, Vermittlungsknoten-Rechner und Verfahren zur Bestimmung eines Kontrollknotens
WO2006026937A1 (de) Verfahren zur nachrichtenübertragung innerhalb einer gruppe von kommunikationsendgeräten
EP1707018B1 (de) Adaptereinheit
DE19827791B4 (de) Verfahren zum Betrieb eines Telekommunikationsnetzes
EP1099326A2 (de) Verfahren zur verbindung von endgeräten mit externen modems
DE102008013349B4 (de) Kommunikationsverfahren und Kommunikationssystem mit Paketabstands- und Paketlängen-Regelung
EP2279603B1 (de) Vorrichtung und Verfahren zur Neuverhandlung einer Multimediaverbindung sowie zugehöriges Kommunikationssystem, digitales Speichermedium, Computer-Programm-Produkt und Computerprogramm

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20051006

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL HR LT LV MK

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

17Q First examination report despatched

Effective date: 20150313

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150724