Title of Invention	"A METHOD OF SENDING INFORMATION/DATA PACKET FROM ONE BRANCH NETWORK TO ANOTHER BRANCH NETWORK IN A TELECOMMUNICATION SYSTEM"
Abstract	The invention relates to a method of sending information/data packet from one branch network A to another branch network B in a telecommunication system comprising a main office network, said main office network having a server, and a plurality of branch network connected via an intermediate network, the method comprising the steps of (a) differentiating at the branch network A whether the traffic is destined for the main office network or another branch network; (b) modifying said traffic destined to said branch network B such that said intermediate network recognises it as being destined for said main office network, so that said traffic is transferred to said main office network instead of to said originally addressed branch network B; (c) said main office network receiving said traffic and recognising it as being destined for said branch network B and modifying said traffic such that it is recognised by said intermediate network and forwarded to said branch network B.

Title of Invention

"A METHOD OF SENDING INFORMATION/DATA PACKET FROM ONE BRANCH NETWORK TO ANOTHER BRANCH NETWORK IN A TELECOMMUNICATION SYSTEM"

Abstract

The invention relates to a method of sending information/data packet from one branch network A to another branch network B in a telecommunication system comprising a main office network, said main office network having a server, and a plurality of branch network connected via an intermediate network, the method comprising the steps of (a) differentiating at the branch network A whether the traffic is destined for the main office network or another branch network; (b) modifying said traffic destined to said branch network B such that said intermediate network recognises it as being destined for said main office network, so that said traffic is transferred to said main office network instead of to said originally addressed branch network B; (c) said main office network receiving said traffic and recognising it as being destined for said branch network B and modifying said traffic such that it is recognised by said intermediate network and forwarded to said branch network B.

Full Text	Corporate networks for data communication are often used in the form of headquarters and branch network configurations. These types of corporate networks must increasingly satisfy real-time requirements. In contrast to local networks branch networks are often linked to the headquarters using wide area networks (WANs). For these networks service level agreements (SLAs) are negotiated between corporate network operators and public network operators. SLAs typically include the bandwidth provided, possible class service available and billing agreement. Depending on the scope and level of the quality of service (QoS), thus, WAN links become available resources to be used where possible in the most cost-efficient manner for the network services to be provided. Often the SLA is subject to ongoing monitoring so that the public operators does not charge unjustifiably high tariffs for actual service delivered. Access routers are located at the border of the WAN are used to route and connect entities such as branched office networks to a WAN using appropriate interfaces and utilising the classes of service offered by the public network operator. If these routers are also in charge of identifying, differentiating, and prioritising the actual traffic in realtime, they come up against technical performance limits, since they are optimised for buffering and forwarding IP packets, i.e. they operate up to e.g. layer 3 of the ISO seven layer model (i.e. physical layer link layer and network layer only). What is needed however is a recognition of protocols up to layer 7 (to encode e.g. header, TCP FTP HTPP and ERP levels) and to enable a distinction to be made between packets of different flows of individual applications and in order to be able to sensibly assign these applications to an agreed class-of-service. These types of router are also very costly and often do not even meet the requirements for monitoring SLAs and the traffic occurring in corporate networks as a planning basis. This is why supplementary, highly specific niche products have found their way into these corporate network configurations supplementing access router products with the given functions. In other words these products are known as quality of service and traffic management network devices which supplement so as to identify specific extra layers. In such configurations these devices will be connected between at the local network and immediately before the access router. Such devices mostly have comprehensive monitoring and statistics functions as well as graphical user interfaces which allow corporate network operators to operate them in an intuitive way. These products recognise the various network services of typical corporate networks, prioritise these, suppress none-critical data flows and thereby use the costly wide area network in a most efficient manner. Unfortunately there is also an unresolved problem with such devices that occurs as soon as the branches transfer data packets to each other, i.e. to other branches. This is also referred to as the "Hub & Spoke" problem. This occurs primarily with peer-to-peer applications communicating branch to branch such as the VoIP application, video conferencing etc. This is discussed below. For most client-server based applications deployed in headquarter and branch office scenarios, the servers are located for operational reasons in the head office. The problem with cross network traffic (i.e. traffic/data which is to go from branch to branch) is caused by such traffic being routed by the access routers or the routers in the WAN without it being able to be recorded before hand e.g. for applied traffic management functions by the quality of service management device located at the head office. This also would sometimes allocate a particular bandwidth. This means that the quality of service characteristics of other traffic can be disturbed on the receiver side in the branches. In other words it is important that head office manages all traffic including branch to branch traffic, but currently networks such as WAN have autonomous routers which work independently and will route without knowledge in the head office and thus nothing is recorded. One possible solution is already being realised in an number of quality of service management network devices by using logical links which are configured on top of the physical access link to the WAN in the headquarter destined to each of the different branch offices. A disadvantage of this solution is the associated segmentation of the physical link and thereby under some circumstances the associated waste of resources as well as the bad scalability properties of this solution. It is an object of the invention to provide a method to overcome all of the above disadvantages and such that all traffic is monitored by the head office. The invention comprises The invention will be descried with reference to the following figure of which: Figure 1 shows a general view of a head office and a plurality of branches. Figure 2 shows the functional units of a head office system and a branch system utilised in a preferred embodiment of the invention. Figure 3 shows a flow diagram representing the steps according to a method of a preferred embodiment of the invention. Figure 1 shows a typical head office and branch network configuration with a head office (Z) and three branches (A, B, C). Various IP sub-networks of the LAN are connected via a Wide Area Network (WAN) via the quality of service network management devices. The quality of service management network devices at the branch networks differentiate their communication partners in accordance with head offices and branches. When cross-network traffic occurs the branch device recognises they are destined for another branch office, it encapsulates the data (e.g. IP packets) before transmitting them into a container IP packet which is addressed with the IP destination address of entity located at the head network. This is usually to a software station of the central device/server in the head network. This is referred to as "tunnelling" which effectively create a virtual address. In other words due to the particular manipulation of outgoing traffic from a branch the WAN will not recognise the data as being destined for another branch, but will see it as destined for the head office. In order to reduce the additional tunnelling overhead, the packet header is preferably compressed for longer-duration connections. This can be undertaken at various levels, e.g. IP-, UDP/TCP, RTP ,,Header Compression". If the maximum transfer size of the packet is exceeded the packet must in any event be segmented beforehand. The WAN (intermediate network) transfers these runnels packets to the head office instead of to the originally addressed partner branches. On the receiver side at the head office device these tunnelled packets are terminated by a software station. Here the tunnelling container, i.e. the virtual address to which the packet is sent, is removed, and if compressed the header will be decompressed. The packet /traffic and the packet is included in LAN-side traffic before handling, i.e. classification and prioritisation. This means that the packets finally reach their intended destination in the partner branches. The advantage is that cross-network traffic is also recorded and handled in the head offices and that this is done without expensive administration. The bandwidth requirement in the branches is not increased. However the bandwidth requirement in the head offices increases by the amount of the cross-traffic and the devices in the head offices must provide a correspondingly more powerful performance. A comprehensive and contemporary solution of the Hub&Spoke problem is therefore specified in accordance with the invention. Figure 2 shows more detail of the functional units. The head office implements a software station which can be addressed via a specific IP address (IPSW)- The branch office equipment (A,B.Q know this IP address. The software station at head office implements the following functional units: IPsw filter, IP tunnel and optional protocol detection with the corresponding header decompression. The branch equipment classifies the incoming traffic from the branches and additionally detects whether the original addressee is in the branch office of the head office (IPfX filter) If the destination is in another branch office and (if a time-critical traffic class is involved) the packet will be tunnelled (IP tunnel). Optionally, beforehand, (if a VoIP packet is involved for example), RTP header compression is undertaken at the originating branch. Then the tunnel packet is sent to the head office. Here the packets for the software station are sorted (JP^ filter) and assigned to the software station where first the additional DP header added by the originating branch (i.e. of the container (IP tunnel)) is removed and the original header of the packet reconstructed for header decompression. Thereafter the reconstructed packets are re-issued into the LAN-side data flow and are thus handled and evaluated in the same way for classification and prioritisation. Figure 3 a and b respectively show flow diagrams of the steps taken at the branch and head office As mentioned it is preferred to reduce the additional tunnelling overhead the packet header should be compressed for longer transmissions. This can be done at different levels, e.g. IP, UDP/TCP, RTP header compression. In order to reduce the additional effort in the central equipment and for the bandwidth requirement of the head office, tunnelling should be restricted to critical traffic classes such as VoIP cross traffic. No-time-critical cross traffic of lower-priority traffic classes can travel directly between the branches, since as a rule there are no or very low class-of-service requirements here. The traffic between branches and head office itself should be transmitted normally and not tunnelled. WE CLAIM 1. A method of sending information/data packet from one branch network A to another branch network B in a telecommunication system comprising a main office network, said main office network having a server, and a plurality of branch network connected via an intermediate network, the method comprising the steps of: a) differentiating at the branch network A whether the traffic is destined for the main office network or another branch network; characterized in that: b) modifying said traffic destined to said branch network B such that said intermediate network recognises it as being destined for said main office network, so that said traffic is transferred to said main office network instead of to said originally addressed branch network B; c) said main office network receiving said traffic and recognising it as being destined for said branch network B and modifying said traffic such that it is recognised by said intermediate network and forwarded to said branch network B. 2. The method as claimed in claim 1 wherein said modification comprises encapsulating said traffic into a data packet which comprises a new header so as to divert the data packet to the head office. 3. The method as claimed in claim 1 or 2 wherein step b comprises adding a new IP address. 4. The method as claimed in claims 1, 2 or 3 wherein said recognition is performed by recognising a particular encapsulation. 5. The method as claimed in claims 1 to 4 wherein said modification comprises decapsulating said header. 6. The method as claimed in any preceding claims, wherein at said main office network said data packet is recorded and/or managed. 7. The method as claimed in any preceding claims, wherein said modified header is compressed at the branch network. 8. The method as claimed in any preceding claims, wherein said modified header is decompressed at main office network. 9. The method as claimed in any preceding claims, wherein said intermediate network is a WAN. 10.The method as claimed in claim 1, wherein the branch network having means to implement step a and b of claim 1. 11.The method as claimed in claim 1, wherein the main office network having means to implement step c of claim 1.

Full Text

Corporate networks for data communication are often used in the form of headquarters and branch network configurations. These types of corporate networks must increasingly satisfy real-time requirements. In contrast to local networks branch networks are often linked to the headquarters using wide area networks (WANs). For these networks service level agreements (SLAs) are negotiated between corporate network operators and public network operators. SLAs typically include the bandwidth provided, possible class service available and billing agreement. Depending on the scope and level of the quality of service (QoS), thus, WAN links become available resources to be used where possible in the most cost-efficient manner for the network services to be provided. Often the SLA is subject to ongoing monitoring so that the public operators does not charge unjustifiably high tariffs for actual service delivered.
Access routers are located at the border of the WAN are used to route and connect entities such as branched office networks to a WAN using appropriate interfaces and utilising the classes of service offered by the public network operator. If these routers are also in charge of identifying, differentiating, and prioritising the actual traffic in realtime, they come up against technical performance limits, since they are optimised for buffering and forwarding IP packets, i.e. they operate up to e.g. layer 3 of the ISO seven layer model (i.e. physical layer link layer and network layer only). What is needed however is a recognition of protocols up to layer 7 (to encode e.g. header, TCP FTP HTPP and ERP levels) and to enable a distinction to be made between packets of different flows of individual applications and in order to be able to sensibly assign these applications to an agreed class-of-service. These types of router are also very costly and often do not even meet the requirements for monitoring SLAs and the traffic occurring in corporate networks as a planning basis. This is why supplementary, highly specific niche products have found their way into these corporate network configurations supplementing access router products with the given functions. In other words these products are known as quality of service and traffic management network devices which supplement so as to identify specific extra layers. In such configurations these devices will be connected between at the local network and immediately before the access router. Such devices
mostly have comprehensive monitoring and statistics functions as well as graphical user interfaces which allow corporate network operators to operate them in an intuitive way. These products recognise the various network services of typical corporate networks, prioritise these, suppress none-critical data flows and thereby use the costly wide area network in a most efficient manner.
Unfortunately there is also an unresolved problem with such devices that occurs as soon as the branches transfer data packets to each other, i.e. to other branches. This is also referred to as the "Hub & Spoke" problem. This occurs primarily with peer-to-peer applications communicating branch to branch such as the VoIP application, video conferencing etc. This is discussed below.
For most client-server based applications deployed in headquarter and branch office scenarios, the servers are located for operational reasons in the head office. The problem with cross network traffic (i.e. traffic/data which is to go from branch to branch) is caused by such traffic being routed by the access routers or the routers in the WAN without it being able to be recorded before hand e.g. for applied traffic management functions by the quality of service management device located at the head office. This also would sometimes allocate a particular bandwidth. This means that the quality of service characteristics of other traffic can be disturbed on the receiver side in the branches. In other words it is important that head office manages all traffic including branch to branch traffic, but currently networks such as WAN have autonomous routers which work independently and will route without knowledge in the head office and thus nothing is recorded.
One possible solution is already being realised in an number of quality of service management network devices by using logical links which are configured on top of the physical access link to the WAN in the headquarter destined to each of the different branch offices. A disadvantage of this solution is the associated segmentation of the physical link and thereby under some circumstances the associated waste of resources as well as the bad scalability properties of this solution.
It is an object of the invention to provide a method to overcome all of the above disadvantages and such that all traffic is monitored by the head office.
The invention comprises
The invention will be descried with reference to the following figure of which:
Figure 1 shows a general view of a head office and a plurality of branches.
Figure 2 shows the functional units of a head office system and a branch system utilised in a preferred embodiment of the invention.
Figure 3 shows a flow diagram representing the steps according to a method of a preferred embodiment of the invention.
Figure 1 shows a typical head office and branch network configuration with a head office (Z) and three branches (A, B, C). Various IP sub-networks of the LAN are connected via a Wide Area Network (WAN) via the quality of service network management devices.
The quality of service management network devices at the branch networks differentiate their communication partners in accordance with head offices and branches. When cross-network traffic occurs the branch device recognises they are destined for another branch office, it encapsulates the data (e.g. IP packets) before transmitting them into a container IP packet which is addressed with the IP destination address of entity located at the head network. This is usually to a software station of the central device/server in the head network. This is referred to as "tunnelling" which effectively create a virtual address. In other words due to the particular manipulation of outgoing traffic from a branch the WAN will not recognise the data as being destined for another branch, but will see it as destined for the head office.
In order to reduce the additional tunnelling overhead, the packet header is preferably compressed for longer-duration connections. This can be undertaken at various levels, e.g. IP-, UDP/TCP, RTP ,,Header Compression".
If the maximum transfer size of the packet is exceeded the packet must in any event be segmented beforehand. The WAN (intermediate network) transfers these runnels packets to the head office instead of to the originally addressed partner branches. On the receiver side at the head office device these tunnelled packets are terminated by a software station. Here the tunnelling container, i.e. the virtual address to which the packet is sent, is removed, and if compressed the header will be decompressed. The packet /traffic and the packet is included in LAN-side traffic before handling, i.e. classification and prioritisation. This means that the packets finally reach their intended
destination in the partner branches. The advantage is that cross-network traffic is also recorded and handled in the head offices and that this is done without expensive administration. The bandwidth requirement in the branches is not increased. However the bandwidth requirement in the head offices increases by the amount of the cross-traffic and the devices in the head offices must provide a correspondingly more powerful performance. A comprehensive and contemporary solution of the Hub&Spoke problem is therefore specified in accordance with the invention.
Figure 2 shows more detail of the functional units. The head office implements a software station which can be addressed via a specific IP address (IPSW)- The branch office equipment (A,B.Q know this IP address. The software station at head office implements the following functional units: IPsw filter, IP tunnel and optional protocol detection with the corresponding header decompression. The branch equipment classifies the incoming traffic from the branches and additionally detects whether the original addressee is in the branch office of the head office (IPfX filter) If the destination is in another branch office and (if a time-critical traffic class is involved) the packet will be tunnelled (IP tunnel). Optionally, beforehand, (if a VoIP packet is involved for example), RTP header compression is undertaken at the originating branch. Then the tunnel packet is sent to the head office. Here the packets for the software station are sorted (JP^ filter) and assigned to the software station where first the additional DP header added by the originating branch (i.e. of the container (IP tunnel)) is removed and the original header of the packet reconstructed for header decompression. Thereafter the reconstructed packets are re-issued into the LAN-side data flow and are thus handled and evaluated in the same way for classification and prioritisation.
Figure 3 a and b respectively show flow diagrams of the steps taken at the branch and head office
As mentioned it is preferred to reduce the additional tunnelling overhead the packet header should be compressed for longer transmissions. This can be done at different levels, e.g. IP, UDP/TCP, RTP header compression.
In order to reduce the additional effort in the central equipment and for the bandwidth requirement of the head office, tunnelling should be restricted to critical traffic classes such as VoIP cross traffic. No-time-critical cross traffic of lower-priority traffic
classes can travel directly between the branches, since as a rule there are no or very low class-of-service requirements here.
The traffic between branches and head office itself should be transmitted normally and not tunnelled.

WE CLAIM
1. A method of sending information/data packet from one branch network A
to another branch network B in a telecommunication system comprising a
main office network, said main office network having a server, and a
plurality of branch network connected via an intermediate network, the
method comprising the steps of:
a) differentiating at the branch network A whether the traffic is destined for the main office network or another branch network; characterized in that:
b) modifying said traffic destined to said branch network B such that said intermediate network recognises it as being destined for said main office network, so that said traffic is transferred to said main office network instead of to said originally addressed branch network B;
c) said main office network receiving said traffic and recognising it as being destined for said branch network B and modifying said traffic such that it is recognised by said intermediate network and forwarded to said branch network B.

2. The method as claimed in claim 1 wherein said modification comprises encapsulating said traffic into a data packet which comprises a new header so as to divert the data packet to the head office.
3. The method as claimed in claim 1 or 2 wherein step b comprises adding a new IP address.

4. The method as claimed in claims 1, 2 or 3 wherein said recognition is performed by recognising a particular encapsulation.
5. The method as claimed in claims 1 to 4 wherein said modification comprises decapsulating said header.
6. The method as claimed in any preceding claims, wherein at said main office network said data packet is recorded and/or managed.
7. The method as claimed in any preceding claims, wherein said modified header is compressed at the branch network.
8. The method as claimed in any preceding claims, wherein said modified header is decompressed at main office network.
9. The method as claimed in any preceding claims, wherein said intermediate network is a WAN.
10.The method as claimed in claim 1, wherein the branch network having means to implement step a and b of claim 1.
11.The method as claimed in claim 1, wherein the main office network having means to implement step c of claim 1.

Documents:

189-DELNP-2007-Abstract-(17-07-2012).pdf

189-delnp-2007-abstract.pdf

189-delnp-2007-Assignment-(02-11-2012).pdf

189-DELNP-2007-Claims-(17-07-2012).pdf

189-delnp-2007-claims.pdf

189-delnp-2007-Correspondence Others-(04-07-2012).pdf

189-DELNP-2007-Correspondence Others-(17-07-2012)..pdf

189-delnp-2007-Correspondence Others-(17-07-2012).pdf

189-delnp-2007-Correspondence-Others-(02-11-2012).pdf

189-delnp-2007-correspondence-others-1.pdf

189-DELNP-2007-Correspondence-Others.pdf

189-delnp-2007-description (complete).pdf

189-DELNP-2007-Drawings-(17-07-2012).pdf

189-delnp-2007-drawings.pdf

189-DELNP-2007-Form-1-(17-07-2012).pdf

189-DELNP-2007-Form-1.pdf

189-delnp-2007-form-13.pdf

189-delnp-2007-form-18.pdf

189-DELNP-2007-Form-2-(17-07-2012).pdf

189-delnp-2007-form-2.pdf

189-delnp-2007-form-26.pdf

189-DELNP-2007-Form-3-(17-07-2012).pdf

189-delnp-2007-form-3.pdf

189-DELNP-2007-Form-5-(17-07-2012).pdf

189-DELNP-2007-Form-5.pdf

189-delnp-2007-GPA-(02-11-2012).pdf

189-delnp-2007-GPA-(04-07-2012).pdf

189-delnp-2007-pct-220.pdf

189-delnp-2007-pct-237.pdf

189-delnp-2007-pct-304.pdf

189-delnp-2007-pct-409.pdf

189-delnp-2007-pct-416.pdf

189-delnp-2007-pct-search report.pdf

189-delnp-2007-Petition-137-(17-07-2012).pdf

« Previous Patent

Next Patent »

Patent Number

256843

Indian Patent Application Number

189/DELNP/2007

PG Journal Number

32/2013

Publication Date

09-Aug-2013

Grant Date

01-Aug-2013

Date of Filing

08-Jan-2007

Name of Patentee

SIEMENS ENTERPRISE COMMUNICATIONS GMBH & CO. KG

Applicant Address

HOFMANNSTRASSE 51, 81379 MUNCHEN, GERMANY

Inventors:

#	Inventor's Name	Inventor's Address
1	TOTZKE, JURGEN	BLUMENSTER. 49,85586 POING, GERMANY

PCT International Classification Number

H04L 12/46

PCT International Application Number

PCT/EP2005/007070

PCT International Filing date

2005-06-29

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	0415841.6	2004-07-15	U.K.