Patent Application
20050091375
The invention concerns a method for managing connections over a link, which may be a wireless link, in a communication network, in particular a network comprising wired communication busses interconnected with the help of wireless links.
In a network comprising a plurality of interconnected transmission media, the bandwidth available over each transmission medium may not necessarily be the same.
If one considers for example two IEEE 1394 wired serial busses connected together using a 5 GHz ETSI BRAN HiperLAN 2 wireless link, the bandwidth available on each of the wired busses can be of 100 Mb/s or more, while the bandwidth available over the wireless link may be limited to 30 Mb/s. Consequently, the wireless link constitutes a bottleneck for connections using this link.
Supposing the available bandwidth on the wireless link is of 30 Mb/s, a first connection of 20 Mb/s is established between the VCR 13 and the display 15. A second connection between tuner 16 and display 14 can be established, since the link is transparent to devices 16 and 14, but if the bandwidth required for this second connection is greater than the remaining wireless bandwidth, the display 14 will not display proper pictures, if any at all. As far as the application having built the second connection is concerned, the connection was nevertheless established without incident at the IEEE 1394 level, because of the transparency of the link at that level, but in reality not all data or no data at all passes the link.
The European patent application EP 01113121.6, filed on May 29, 2001 in the name of Thomson Licensing SA and having the title ‘METHOD FOR MANAGING BANDWIDTH OVER A WIRELESS LINK IN A COMMUNICATION NETWORK’ also concerns this problem.
The invention concerns a method for managing a connection in a communication network comprising a bridge interfacing at least two device clusters, wherein the connection is established between a first device and a second device respectively connected to different clusters characterized in that it comprises the steps, at the level of an application adapted to establish said connection:
According to an embodiment of the invention, the portal is a node of the cluster to which the device establishing the connection is connected, or a central controller of the bridge.
According to an embodiment of the invention, the request for reserving resources comprises an address of the application, for sending notifications.
According to an embodiment of the invention, the address comprises an offset in the address space of the node hosting the application.
According to an embodiment of the invention, the bridge is a wireless bridge comprising an isochronous resource manager, further comprising the step of, further to receiving the resource reservation request, having the portal forward the request to the isochronous resource manager, await its response and transmit the response back to the application.
According to an embodiment of the invention, the method further comprises the step, at the level of the portal, if the reservation is successfully made with the isochronous resource manager, of transmitting parameters of the reservation to all portals involved in the connection.
According to an embodiment of the invention, the step of transmitting parameters to the portals is carried out before the step of forwarding the response of the isochronous resource manager to the application.
According to an embodiment of the invention, a reservation request by the application has a format similar to a reservation request addressable to the isochronous resource manager of the bridge, said reservation request by the application comprising identifiers of the source and sink nodes for the connection, said portal further carrying out the step of replacing the source and sink node identifiers of the reservation request of the application by the identifiers of portals connecting the source and sink nodes to the bridge, and of carrying out the reverse change in the response of the isochronous resource manager.
According to an embodiment of the invention, the method further comprises the step, at the level of the application, of receiving from the bridge topological information for determining which portals of the bridge are involved in a connection.
According to an embodiment of the invention, a reservation request by the application further comprises identifiers of the portals connecting the source and sink nodes of the connection to the bridge.
The invention also concerns a device for connection to a cluster in a communication network comprising a plurality of clusters connected by a bridge, characterized in that it comprises an application for requesting resource reservation for a connection over the bridge and for registering with a portal of the bridge for receiving notifications of events relating to the status of the resources allocated to the connection
Other characteristics and advantages of the invention will appear during the description of a non-restrictive embodiment explained with the help of the attached drawings among which:
Although the embodiment is based on the use of an ETSI BRAN Hiperlan 2 wireless link connecting IEEE 1394 busses, other technologies may be used, be it for the link or the sub-networks. An example of another technology for the link is the Intemet Protocol (‘IP’). Moreover, the links between wired busses need not necessarily be wireless, although this is the case in the embodiment described below.
The reader may find more information concerning IEEE 1394 busses in the standardization documents edited by the Institute of Electrical and Electronic Engineers (IEEE), in particular in Document A: IEEE1394-1995 and Document B: IEEE1394a-2000. Hiperlan 2 is a Broadband Radio Access Network (BRAN) defined by the European Telecommunications Standards Institute (ETSI).
Information concerning the connection of IEEE 1394 networks using Hiperlan 2 can be found in particular in the document C: ETSI TS 101 493-3 V1.2.1B (2001-010)—Technical Specification—Broadband Radio Access Networks (BRAN)—HIPERLAN Type 2—Packet based convergence layer—Part 3: IEEE 1394 Service Specific Convergence Sublayer (SSCS), and in the document D: ETSI TS 101 493-4V1.1.1 (2001-07)—Technical Specification—Broadband Radio Access Networks (BRAN)—HIPERLAN Type 2—Packet based convergence layer—Part 4: IEEE 1394 Bridge Specific Functions Sublayer.
A last document for background information is document E: IEC 61883 ‘Digital Interface for Consumer AudioNideo Equipment’, published by the International Electrotechnical Commission. The first part in particular describes the establishment of connections between input and output plugs of listener and talker devices.
According to the present embodiment, the HL2 nodes 207, 208 and 213 are not transparent to the other devices, in the sense that they are also considered to be nodes on their respective busses, i.e. they are attributed a physical identifier after a bus reset. At the level of the IEEE 1394 layers however, the link is transparent: all nodes are considered to be on a single bus and physical identifiers are attributed accordingly after a reset. HL2 nodes 207 and 208 issue self identification packets to represent nodes on their respective clusters when bus resets are carried out.
Each node comprises an IEEE 1394 software stack, i.e. the physical layer, the link layer and the transaction layer, as well as an application layer. Each HL2 node also comprises these layers on their wired bus interface. Lastly, the HL2 nodes communicate using the Hiperlan 2 protocol stack.
A Hiperlan 2 network comprises a node acting as Central Controller, and with which wireless nodes register. The Central Controller is also in charge of allocating resources in the Hiperlan 2 wireless frame. Document C defines an Isochronous Resource Manager (‘IRM’), located in the IEEE 1394 Service Specific Convergence Sublayer (SSCS) of the Central Controller. The purpose of the HL2 IRM is to provide channel and bandwidth reservation facilities, although it does not provide CHANNEL_AVAILABLE and BANDWIDTH_AVAILABLE registers as its IEEE 1394 counterpart. Since different physical modes are possible between a listener node and a talker node on the wireless link, the available bandwidth depends on the talker and on the listener.
One of the issues raised while streaming an isochronous stream over a wireless network is that the amount of time slots to be reserved in the wireless frame depends on the location of the source and the destination. Different sources and destinations may not use the same modulation scheme, and therefore may not have the same requirements in terms of time slots in the frame. The selection of a modulation scheme (physical mode) depends on the link budget between the source and the destination. This has been the rationale when defining the 1394 SSCS to modify the IEC-6 1883 CMP protocol as described in document E and to adapt it to the constraints of a wireless environment.
According to the present embodiment, the HL2 IRM interface as described in the Annex A.4 of document C is made accessible to the HL2 aware applications.
It may happen that the link budget decreases for a given stream over the time so that a stream may be broken after a certain period of time. According to the present embodiment, an event mechanism is defined so that an application may be informed when a stream is broken over the HL2 network.
A wired HL2 aware application is defined as an application running on a wired device, but aware of the existence of the transparent bridge using a HiperLAN/2 network. The processes defined in the present description for this HL2 aware application are optional. If they are not implemented, they do not prevent streaming to be established over the wireless network. But if they are implemented, they allow an application to know whether the resource reservation was successful or not. It also allows it to be informed of whether a connection is broken.
The nodes will be designated as follows:
A node is identified as a HL2 node if it contains a unit directory at a predetermined offset in its configuration ROM as specified by document D. This unit directory contains parameters called ‘specifier_ID’ and ‘version’, which enable any IEEE 1394 node to verify whether the node under consideration is a HL2 node or not. Respective values of 0180c216 and 00020016 characterize a HL2 node.
The HL2 unit directory also contains an entry describing the address offset to be used to send lock commands. This address offset is in the unit space starting at 0xFFFF F000 0800 as described in IEEE 1212 Section 4.2. The format of this entry is as indicated in
A description of the HL2 IRM interface will now be given.
According to the present embodiment, a HL2 aware application examines the configuration ROM of the nodes of its local bus. It will thus detect which nodes contain a HL2 unit directory, and thus which nodes are HL2 nodes.
The 1394 SSCS layer of the Central Controller contains an HL2 IRM, the interface of which is described in the 1394 SSCS Technical Specification (document C).
A wireless 1394 application usually sends lock commands to make resource reservations on a serial bus.
When a HL2 aware application (running on a wired device, e.g. node 209) detects the presence of HL2 nodes on its local bus, it uses, according to the present embodiment, the same commands to open and close isochronous streams as specified by the 1394 SSCS document. Since a wired application does not necessarily know on which node the HL2 IRM runs, it is proposed that the wired application sends these commands to its parent HL2 node (after consulting an appropriate internal topology map)—in the case of the example of
According to a variant embodiment, this address may also be fixed and not is necessarily coded in the HL2 unit directory entry.
The parent wireless node 209 knows on which HL2 node (207) the HL2 IRM runs. When it receives a lock command, it relays this command to the HL2 IRM behaving as a proxy. When the HL2 IRM sends back the lock response to the parent wireless node 207, it relays this response back to the application.
The parent wireless node of the HL2 aware application that has relayed a successful lock command (i.e. the HL2 aware application action has been successfully completed by the HL2 IRM) configures the HL2 iPCR and oPCR plug control registers of the HL2 parent nodes of the listener and the talker respectively with the corresponding payload value so that the HL2 isochronous reservation protocol can be completed, without any further action by the HL2 aware application.
The new commands will now be described:
The new commands are based on the HL2 request/response system. The required commands allow to allocate a channel, to allocated a certain quantity bandwidth, to release channel and bandwidth, and to reallocate after bus reset. The generic message format is shown in
The parameters are as follows:
‘command’: the command of the request as detailed in Table 1
‘status’: the status of the response as detailed in Table 2
The commands will be described in two steps:
1. ALLOCATE_SOME command
1.1 Parameters
Fields used differently compared to the HL2 1394 SSCS specification are underlined, both in the text and in
status: response status as described below.
The HL2 aware application uses the node ID of the real talker and listener (even if these are wired nodes) in the talker_ID and listener_ID field of the ALLOCATE_SOME lock command. This command is sent to the parent HL2 node of the application.
1.2 HL2 nodes behavior
The parent wireless node knows on which HL2 node the IRM runs. It also knows the topology map of the wireless network. When it receives an ALLOCATE_SOME lock command, it removes the channel field (to generate a HL2 SSCS lock command) and converts the real talker_ID and listener_ID into the node_ID of their respective wireless parent nodes. It also converts the 1394 payload field into the HL2 payload field (The payload values are expressed differently on the IEEE1394 bus and on Hiperlan2). It then relays this command to the HL2 IRM behaving as a proxy.
When it receives the IRM lock response, the parent wireless node replaces the wireless channel allocated by the HL2 IRM with the wired 1394 channel. It also replaces the talker_ID, listener_ID and payload fields with their initial wired 1394 values, and then relays this response back to the application.
The parent wireless node stores the channel values to carry out a mapping between the Hiperlan2 channel and the [EEE1394 channel. It also stores the notification_CSR_offset fields that will be further used to notify the HL2 aware application when the allocated bandwidth over the link cannot be guaranteed anymore. See the section on Event notification below for more details.
The parent wireless node then generates “inter transparent bridge management” commands (e.g. lock based commands, or write requests to some specific registers) to communicate the HL2 talker node and HL2 listener node the mapping of the HL2 wireless channel to the 1394 wired channel.
Eventually, as described above, the parent HL2 wireless node configures the iPCR and oPCR of the HL2 parent nodes of the talker and listener respectively, as described in the 1394 SSCS (document C).
2. MODIFY_BANDWIDTH Command
2.1 Parameters
This call is used to modify the bandwidth on an already allocated channel. The payload value replaces the former one. When called with a null value for the payload, the channel is not released. This command is sent by the application to the parent HL2 node of the application.
2.2 HL2 nodes behavior
The HL2 parent node intercepts this command. It translates the channel and payload fields into the corresponding HL2 channel and payload fields and relays this command to the HL2 IRM. The HL2 parent node receives the lock response from the IRM and modifies the HL2 channel and payload fields before sending the response back to the HL2 aware application.
3. RECLAIM_THIS command
3.1 Parameters
This call is used to reallocate the channel and bandwidth after a Bus Reset. This command is sent to the parent HL2 node of the application.
3.2 HL2 node behavior
If bus resets are propagated over the HL2 bus as HL2 bus resets, the HL2 parent node intercepts this command. It translates the channel and payload fields into the corresponding HL2 channel and payload fields and relays this command to the HL2 IRM. The HL2 parent node receiving the lock response from the IRM, translates back the HL2 channel and payload fields and sends it back to the HL2 aware application.
4. RELEASE_THIS Command
4.1 Parameters
This call is used to release the channel and its associated bandwidth. This command is sent to the parent HL2 node of the application.
4.2 HL2 node behavior
The HL2 parent node intercepts this command. It translates the channel field into the corresponding HL2 channel field and relays this command to the HL2 IRM. The HL2 parent node receiving the lock response from the IRM, translates back the HL2 channel field and sends it back to the HL2 aware application.
Event notification will now be described.
As mentioned in the introduction, the specificity of a wireless network like Hiperlan2 is that the bandwidth capability depends on the link budget, which is a dynamic parameter. A notification mechanism is defined hereafter to notify the application of any problem at this level.
With the ALLOCATE_SOME request, the application provides the HL2 parent node with an address offset for this notification. This offset identifies a specific register in the CSR space of the application's 1394 node. With this mechanism, every application can have a specific register for this purpose.
When a problem occurs on the HL2 bus, the HL2 parent node is informed via the HL2 bus event mechanism (using the HL2_CSR dedicated to event notification defined in the 1394 SSCS Annex A). To inform the application of a bandwidth problem, the HL2 parent node performs a 1394 Quadlet Write Request on this register, according to the format given by
The ‘status’ parameter indicates the reason of the bandwidth problem, as indicated by Table 3.
The ‘channel’ parameter indicates the 1394 channel which is affected by the problem. This parameter allows the application to identify the stream concerned by the problem.
The connection processes will now be described.
Several methods that a HL2 aware application follows according to the present embodiment are presented. They concern the creation of a connection, the destruction of a connection, the re-establishment of a connection after a bus reset, and the overlaying of a connection.
1. Creation
In order to set up a connection, an application performs at least some of the following steps:
The order of actions is indicative, other combinations are also possible.
b 2. Destruction
To close a connection, an-application carries out at least some of the following steps:
Note that step 3 could also be done just after step 1.
3. Re-establishment after bus reset
The bus reset is propagated over the HL2 network, so the application which built the connection is aware that a bus reset occurred, even if it is at the other side of the HL2 network. The re-establishment basically follows the same rules as the creation of a connection, except that the ALLOCATE_SOME lock command is replaced by a RECLAIM_THIS lock command.
4. Overlay
To overlay a connection, an application has to ask for the topology map of the wireless network, check if the wireless network is on the path between the source and the sink, and deduce whether bandwidth has to be reserved on the HL2 link. If the wireless network was not on the path before, an ALLOCATE_SOME command has to be generated, and the process is then that of a connection. Writing in the iPCR of the new listener of the connection is also performed.
If the available link budget is not sufficient for that new listener, the application can rely on a notification message as described in the section on event notification.
Relation with resource reservation initiated by the transparent bridge:
The transparent bridge intercepts PCRs lock responses to trigger resource reservations over the HL2 bus. These resource reservations may sometimes collide with resource reservations triggered by HL2 aware applications. The issue is solved as follows:
HL2 aware applications are required to first reserve HL2 resources (send the ALLOCATE_SOME command), and only afterwards send a lock request and responses to node PCRs.
After a successful HL2 resource reservation (the parent node received a positive ALLOCATE_SOME response from the IRM), the HL2 parent node is required to send inter-bridge management commands (either lock based commands or quadlet write based commands) to other HL2 nodes, in order to inform them of the existence of the HL2 channel and the current mapping with a 1394 channel.
According to the present variant, the HL2 parent node sends inter-bridge management commands before relaying the ALLOCATE_SOME response to the HL2 aware application. Every HL2 node will then be informed of the establishment of this HL2 channel before intercepting PCR lock responses. Thus these HL2 nodes will not try to make the same reservation again when receiving the PCR lock responses.
The following variants can be applied to the above embodiment:
(a) The 1394 application transmits to the HL2 parent node the physical identifiers (‘PhyIDs’) of the HL2 parent talker and listener nodes, within the ALLOCATE_SOME message. This simplifies the task of the HL2 parent node, which does not need to determine this information by itself.
(b) The 1394 application sends the lock commands (ALLOCATE_SOME etc . . . ) to a specific, predetermined HL2 node (e.g. the Central Controller) and not to its link parent. The predetermined HL2 node then determines the HL2 parent node of the 1394 application.
(c) A new request (called e.g. ‘SUBSCRIBE’) is defined to allow an application to subscribe to events independently from a resource reservation. In other words, the application will receive events relating to channels it specifies in the request. A request ‘UNSUBSCRIBE’ is also defined.
(d) Possibility to remove the RECLAIM_THIS request, because a 1394 bus reset does not cause a HL2 bus reset, and vice-versa.
The invention allows an application to know whether it is possible or not to establish the required stream.
It allows cleaner management of the link resources.
It is compliant with 1394-1995 and the 1394a-2000 optimization algorithms for connection management.
It works with networks interconnecting two or more 1394 clusters.
It allows an application to warn the user in case of impossibility of stream establishment. This may lead to smart algorithms suggesting to the user that with a different topology map the network would work better, by putting on the same side of the wireless link source and sink that are usually used together. Referring to the example of
| Number | Date | Country | Kind |
|---|---|---|---|
| 01403016.7 | Nov 2001 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP02/13300 | 11/25/2002 | WO |
