Method for aggregating data traffic over an access domain and nodes therefor
18 claims: 4 independent, 14 dependent
- 1アクセスドメイン上でデータトラフィックを集合するアクセスエッジノードであり、前記アクセスドメインは、ユーザドメインとサービスプロバイダドメインとの間でデータトラフィックを運び、前記アクセスエッジノードは、サービスエージェントユニット、サービスバインディングユニット、入出力ユニット、および制御ユニットより構成され、 前記サービスエージェントユニットは、サービスエージェントを 提供 し、それぞれの前記サービスエージェントは、1つの前記サービスプロバイダドメインに対応し、対応する1つの前記サービスプロバイダドメインに対して、前記アクセスドメイン上で仮想ローカルエリアネットワークを保持し、 前記サービスバインディングユニットは、存在するサービスバインディング情報を 提供 し、それぞれの前記サービスバインディング情報は、1つの前記サービスエージェントの属性、ユーザドメイン情報、アクセスドメイン転送プリミティブを含み、 前記入出力ユニットは、前記サービスプロバイダドメイン、前記アクセスドメイン、および前記アクセスドメインと前記ユーザドメインとに接続を提供するアクセスノードと通信し、さらに、前記入出力ユニットは、サービス要求関連メッセージを受信し、前記サービス要求関連メッセージは、1つの前記サービスプロバイダドメインおよび1つの前記ユーザドメインを識別し、 前記制御ユニットは、前記入出力ユニットでサービス要求関連メッセージを受信すると、1つの前記サービスエージェントが、前記サービス要求関連メッセージ中で識別された前記サービスプロバイダドメインに対応するかどうかを決定し、もし、対応する前記サービスプロバイダドメインが存在すれば、前記サービスバインディングユニットの中で、対応するサービスバインディングを作成し、作成された前記サービスバインディングに従って、受信した前記サービス要求に関連するデータトラフィックを送信するために、前記サービス要求メッセージの中で識別された前記ユーザドメインに接続を提供するアクセスノードに情報を伝達することを特徴とする、アクセスドメイン上でデータトラフィックを集合するアクセスエッジノード。
- 2前記サービスバインディングユニット内で対応するサービスバインディングを作成することが、前記ユーザドメインを、要求された前記サービスプロバイダに対応する前記仮想ローカルエリアネットワークに追加することに対応し、その際、前記サービスバインディングユニット内に、要求されたサービスプロバイダに対応する前記サービスエージェントの属性、ユーザドメイン情報、およびアクセスドメイン転送プリミティブを持つエントリを追加することによって、要求された前記サービスプロバイダに対応する前記仮想ローカルエリアネットワークに追加することを特徴とする、請求項1に記載のアクセスエッジノード。
- 3前記入出力ユニットが、さらに、サービスプロバイダドメイン入出力ユニットとアクセスドメイン入出力ユニットから構成されており、 前記サービスプロバイダドメイン入出力ユニットは、前記サービスプロバイダドメインと通信するために設けられており、 前記アクセスドメイン入出力ユニットは、前記アクセスドメインおよびアクセスノードと通信するために設けられており、前記アクセスノードは、前記アクセスドメインと前記ユーザドメインとに接続を提供し、さらに、前記アクセスドメイン入出力ユニットは、前記サービスプロバイダドメインから前記サービス要求関連メッセージを受信し、前記サービス要求関連メッセージが、1つの前記サービスプロバイダドメインおよび1つの前記ユーザドメインを識別することを特徴とする、請求項2に記載のアクセスエッジノード。
- 4それぞれの前記サービスバインディングの前記アクセスドメイン転送プリミティブが、少なくとも1つのユーザドメインMACアドレス、ユーザドメインローカルネットワークコンテキスト、および仮想アクセスノードMACアドレスを含むことを特徴とする、請求項2に記載のアクセスエッジノード。
- 5いくつかの前記サービスバインディングが、イーサネットユニキャストサービスバインディングであることを特徴とする、請求項2に記載の前記アクセスエッジノード。
- 6いくつかの前記サービスバインディングが、イーサネットマルチキャストサービスバインディングであることを特徴とする、請求項2に記載の前記アクセスエッジノード。
- 7前記サービスバインディングユニットが、1つのユーザドメインに対して複数のサービスバインディングを 提供 することを特徴とする、請求項2に記載の前記アクセスエッジノード。
- 8アクセスドメイン上でデータトラフィックの集合を行う方法で、前記アクセスドメインは、複数のサービスプロバイダドメインと複数のユーザドメインとの間でデータトラフィックを運び、前記方法は、 アクセスエッジノード内で複数のサービスエージェントを構築し、それぞれのサービスエージェントは、1つの前記サービスプロバイダドメインに対応し、対応する前記サービスプロバイダドメインに対して、アクセスドメイン上で仮想ローカルエリアネットワークを保持するステップと、 前記アクセスエッジノードで、サービス要求関連メッセージを受信した時に、前記サービス要求関連メッセージが、1つの前記サービスプロバイダドメインおよび1つの前記ユーザドメインを識別し、構築された1つの前記サービスエージェントが、要求された前記サービスプロバイダドメインに対応するかどうかを決定するステップと、もし、1つの構築された前記サービスエージェントが、識別された前記サービスプロバイダドメインに対応すれば、 前記アクセスエッジノードにおいて、受信した前記サービス要求関連メッセージのためにサービスバインディングを作成し、このとき、前記サービスバインディングは、対応する前記サービスエージェントの属性、識別されたユーザドメイン情報、およびアクセスドメイン転送プリミティブを含むステップと、 識別された前記ユーザドメインと前記アクセスドメインに接続を提供する前記アクセスノードに、前記サービスバインディングが作成されたという情報を伝達するステップと、 作成された前記サービスバインディングに従って、識別された前記ユーザドメインと識別された前記サービスプロバイダとの間のデータトラフィックを集合するステップとより構成されることを特徴とする、アクセスドメイン上でデータトラフィックの集合を行う方法。
- 9サービスバインディングを作成する前記ステップが、要求された前記サービスプロバイダに対応する前記仮想ローカルエリアネットワークに、前記ユーザドメインを追加することに対応することを特徴とする、請求項8に記載の方法。
- 10それぞれの前記サービスバインディングの前記アクセスドメイン転送プリミティブが、少なくとも1つのユーザドメインMACアドレス、ユーザドメインローカルネットワークコンテキスト、および仮想アクセスノードMACアドレスを含むことを特徴とする、請求項9に記載の方法。
- 11いくつかの前記サービスバインディングが、イーサネットユニキャストサービスバインディングであることを特徴とする、請求項9に記載の方法。
- 12存在する仮想ローカルエリアネットワークの1つが、マルチプロトコルラベルスイッチングの確保された経路であることを特徴とする、請求項10に記載の方法。
- 13アクセスドメイン上でデータトラフィックを集合するアクセスノードであり、前記アクセスドメインは、ユーザドメインとサービスプロバイダドメインとの間でデータトラフィックを運び、前記アクセスノードは、入出力ユニット、集合ユニット、および制御ユニットより構成され、 前記入出力ユニットは、前記アクセスドメイン上で、前記ユーザドメインからデータトラフィックを受信し、前記ユーザドメインから受信したデータトラフィックを転送し、 前記集合ユニットは、前記アクセスドメイン上で存在するサービスバインディングに関する情報を格納し、前記情報は、それぞれのサービスバインディングに対し、前記アクセスドメイン上で、サービスプロバイダドメインに対応する仮想ローカルエリアネットワークの属性を持つユーザドメインの属性と、前記サービスバインディングの識別とを含み、 前記制御ユニットは、1つの前記ユーザドメインからデータトラフィックを受信したときに、そのデータトラフィックが1つの存在する前記サービスバインディングに対応するかどうかを、前記集合ユニット内のユーザドメイン属性と比較することによって決定し、もし、前記ユーザドメイン属性が1つの存在する前記サービスバインディングに対応すれば、対応する前記サービスバインディングに従って、 前記 アクセスドメイン上で受信したそのデータトラフィックを集合することを、前記入出力ユニットに情報伝達することを特徴とする、アクセスドメイン上でデータトラフィックを集合するアクセスノード。
- 14いくつかの前記サービスバインディングが、イーサネットユニキャストサービスバインディングに対応することを特徴とする、請求項13に記載のアクセスノード。
- 15前記入出力ユニットが、さらに、ユーザドメイン入出力ユニットとアクセスドメイン入出力ユニットから構成されており、 前記ユーザドメイン入出力ユニットは、前記ユーザドメインからデータトラフィックを受信し、 前記アクセスドメイン入出力ユニットは、前記アクセスドメイン上で前記ユーザドメインから受信したデータトラフィックを転送することを特徴とする、請求項13に記載のアクセスノード。
- 16前記アクセスドメイン入出力ユニットが、イーサネットベースの入出力ユニットであることを特徴とする、請求項15に記載のアクセスノード。
- 17前記アクセスドメイン入出力ユニットが、IPネットワーク入出力ユニットであることを特徴とする、請求項15に記載のアクセスノード。
- 18少なくとも1つの仮想ローカルエリアネットワークが、マルチプロトコルラベルスイッチングの確保された経路に対応することを特徴とする、請求項14に記載のアクセスノード。
Independent claims18
51 paragraphs, as filed
Priority statement under 35 USCS119 (e) and 37 CFRS 1.78. The patent application was filed on February 14, 2005 in the names of Sylvain Monette, Mathieu Giguere, Marthin Julien and Benoit Tremblay. Application No. 60 / 651,971 "Poly project" and the names of Sylvain Monette, Mathieu Giguere, Marthin Julien and Benoit Tremblay. Claims priority under US Provisional Patent Application prior to Application No. 60 / 674,307, "Access node-edge node complex protocol (AEP)" filed April 25, 2005. It is a thing.
The present invention relates to a method of collecting data traffic on an access domain, and an access node and an access edge node that collect data traffic according to the present method.
In recent years, there has been an explosive increase in Internet Protocol (IP) networks. Initially, it was developed to allow universities and researchers to communicate and collaborate on research projects, but it has grown into a network offered at the huge market level. Today, ordinary households connect to IP networks to use the Worldwide Web, play interactive games, carry voice over IP, download documents and software, and conduct e-commerce. It's becoming normal to do.
Hereinafter, FIG. 1 will be described. FIG. 1 is an explanatory diagram showing a conventional technical example of the IP network 100. Typically, an IP network consists of an access domain 115, a network service provider domain 140, and an application service provider domain 150. The access domain 115 includes an access node (AN) 120 and an access network 130 such as an IP network. The access node 120 is an access provider that provides the user domain 110 with a connection to the IP network 130. The user domain 110 includes, for example, a user device (UD) (computer, mobile phone, personal digital assistant (PDA), etc.), a local area network (LAN), and a wireless LAN (W-LAN). .. The user domain communicates with the access node using various possible technologies. These technologies include dial-up connection over telephone lines and ADSL (Asymmetric Distribution Subscriber). There are Line) connections, cable modem connections over TV cable networks, and wireless communication. Access network 130 consists of a group of independent switches and routers. The role of switches and routers is to switch / route incoming data traffic based on the destination address embedded in the data traffic. The network service provider domain 140 is suitable for voice transmission services on IP, for example, while the application service provider domain 150 is suitable for electronic banking and electronic commerce.
Figure 1 depicts three user domains, two access nodes, two service provider domains, and two application service domains, but typically an IP network 100 has thousands of user domains and dozens. Includes access nodes and hundreds of network service provider domains and application service provider domains. For access network 130, it is common to encounter networks with hundreds of switches and / or routers. Thus, Figure 1 depicts the IP network 100, which is extremely simplified for clarity.
The IP protocol was developed in the early 1970s to ensure the exchange of centralized data traffic and messages over such IP networks. IP version 4 (IPv4) is used in most of today's well-developed IP networks. IPv4 is an address allocation method that uses 32 bits and can allocate 4,294,967,296 possible addresses. Each assigned address is unique and directly identifies one device. In the case of IP network 100 as shown in FIG. 1, it is generally known that the network is based on Ethernet-based data links. Ethernet-based data links provide a fast and concise exchange for data traffic and messages throughout the IP network 100.
However, due to the increasing number of devices communicating over IP networks and the inherent limitations of IPv4, the IP community needs a new fix for IP: IP Version 6 (IPv6). This new version is based on a 128-bit address allocation scheme and can offer more possible addresses.
Both IPv4 and IPv6 are "best effort" protocols, even though IPv6 allows for a larger number of IP addresses and the shortfall of address allocation seen in IPv4. Best effort means that when a network carries data traffic, it does not make any special efforts to increase its probability or the quality of service required for those types of data traffic. This method is sufficient for some network service providers 140 and application service providers 150, but unfortunately it does not provide sufficient functionality for others. Thus, some network service providers 140 and application service providers 150 cannot provide services so easily and smoothly on the IP network 100.
To solve this problem, MultiProtocol Label Switching (MPLS) is used on IP networks. MPLS is based on protocols such as Reservation Protocol (RSVP), which maintains a consistent quality of service and secures routes on the IP network 100. RSVP first secures a route through a series of routers. To secure a route, each router adds an entry to its MPLS table. The entry points to data traffic that arrives at a particular ingress port and has a predetermined label, a corresponding egress port, and a label to be used. By creating a secured route within the IP network 100, it is possible to carry data traffic over a large contiguous range of network service provider 140 and application service provider 150.
However, with the increasing number of network service providers 140 and application service providers 150 that require higher quality of service than "best effort", and the possibility that user domains 110 and these user domains 110 will use access network 130. With the growing number of access nodes 120 that need to be increased, MPLS has proved not to be a good option.
The principles of early IP networks are based on routers that process incoming data traffic with as few operations as possible before routing it to its final destination. A best effort network is also a widely recognized concept that is a trade-off between quality of service and volume of data traffic. The higher the quality of service, the less data traffic is carried by the same number of routers. IP networks have not been designed with a high level of quality of service in mind. In this way, creating a secured route for high quality of service of data traffic on the IP network reduces the amount of data traffic on the IP network as a direct result. In addition, the reserved routes required for MPLS as described above result in more effort being spent on routing at each router on the reserved routes. The routing efforts mentioned above are less significant when a few secured routes are opened at the same time, but now that services have advanced, applications demand more than "best effort" quality of service. It is easy to imagine that thousands of secured routes are required at the same time on an IP network. Retaining and routing data traffic while having a large number of reserved routes further strains the router and reduces the routing capacity of the affected router. Therefore, the current use of MPLS for quality of service improvements on IP networks results in reduced data traffic exchanges and slowed data traffic. Such an impact is unacceptable as it directly affects the entire data traffic rather than part of the secured route.
Currently, there is no known solution to the problem that leads to an increase in the number of user devices and the number of service providers that provide services on IP networks. Moreover, long-term solutions have not yet been identified to enable substantive and constructive solutions to the increased need for QoS for specific services and applications.
<p> Therefore, to overcome the shortcomings and shortcomings of existing solutions, nodes that allow thousands of network service provider domains and application service provider domains to efficiently communicate with user domains on the access domain. The advantages of having a method should be evaluated immediately. While offering different levels of service quality, it is also advantageous to have nodes and methods that consider the use of a centralized access network. The present invention provides the methods and nodes described above.</p>
<p> The present invention allows thousands of network service provider domains and application service provider domains to efficiently communicate with user domains on an access domain by aggregating data traffic. The methods and nodes for aggregating data traffic of the present invention relate to the concept of service binding that provides centralized use of access domains and various levels of service quality.</p><p> To do so, according to one aspect of the invention, it is embodied in an access edge node that aggregates data traffic on the access domain. Here, the access domain carries data traffic between the user domain and the service provider domain. The access edge node of the present invention includes a service agent unit, a service binding unit, an input / output unit, and a control unit. The service agent unit hosts the service agent. Each service agent corresponds to one service provider domain and maintains a virtual local area network on the access domain for the service provider domain. The service binding unit hosts existing service binding information. Each service binding contains one service agent attribute, user domain information, and access domain transfer primitive. The I / O unit communicates with the service provider domain and access node. The access node provides the user domain with a connection to the access domain. The I / O unit receives service request related messages that identify one service provider domain and one user domain. When the control unit receives a service request-related message on the I / O unit, it determines whether one service agent corresponds to the service provider domain identified in the service request-related message. If one service agent corresponds to the service provider domain identified in the service request related message, the control unit creates the corresponding service binding in the service binding unit and follows the created service binding. , The identified user domain sends data traffic to the identified service provider domain to the access node that provides the connection to the identified user domain in the service request message.</p><p> According to one aspect of the invention, creating a service binding within a service binding unit involves adding a user domain to the requested service provider and the corresponding VLAN. At that time, the user domain is added to the requested service provider and the corresponding VLAN by adding an entry in the service binding unit. The entry has the service agent attributes, user domain information, and access domain transfer primitives that correspond to the requested service provider.</p><p> Another aspect of the invention relates to a method of aggregating data traffic on an access domain that carries data traffic between multiple service providers and user domains. The method involves building multiple service agents within the access edge node. Each service agent corresponds to a virtual local area network on the access domain for one service provider domain. When a service request-related message is received at the access edge node, the service request-related message identifies one service provider domain and one user domain, and one of the constructed service agents corresponds to the requested service provider domain. A step is taken to determine if, and if one of the constructed service agents corresponds to the requested service provider domain, create a service binding for the received service request related message on the access edge node. The service binding contains the corresponding service agent attributes, information about the user domain, and access domain transfer primitives. This method continues to convey information to the access node. This access node is responsible for providing connectivity to the identified user domain and the access domain for which the service binding was created. Subsequently, the method aggregates the data traffic for the identified service provider received from the identified user domain according to the created service binding.</p><p> Another aspect of the invention relates to an access node that aggregates data traffic on an access domain. Here, the access domain carries data traffic between the user domain and the service provider domain. Access nodes include I / O units, collective units, and control units. The I / O unit receives data traffic from the user domain and forwards the data traffic received from the user domain on the access domain. Aggregate units store information about service bindings that exist on the access domain. Here, the service binding information existing on the access domain is like the identification of the service binding and the attribute of the user domain having the attribute of the corresponding service provider. When the control unit receives information from one user domain, it determines whether the received data traffic corresponds to one of the existing service bindings. The determination process is performed by comparing the attributes of the user domain and the service provider domain in the aggregate unit. If it corresponds to a service binding that has user domain and service provider domain attributes, the control unit informs the I / O unit that it collects the data traffic received on the access domain according to the identified service binding. introduce.</p>
For a more detailed understanding of the objects and advantages of the present invention, the description will be given together with the accompanying drawings described below. Innovative disclosures of the present invention are described by individually referring to examples of various embodiments. However, it should be understood that this type of embodiment provides only a few examples of the numerous advantageous uses of the innovative disclosures of the present invention. In general, what is described in the specification of the present application does not necessarily limit any of the various required items of the present invention. Moreover, some statements apply to the characteristics of some inventions, but not to the characteristics of other inventions. In the figure, the same or similar elements are indicated by the same code throughout several charts.
The present invention provides a method and a node for efficiently collecting data traffic. This data traffic is data traffic sent from or sent to a plurality of user domains communicating with the service provider domain. To that end, access edge nodes are deployed within the access domain between the user domain and the service provider domain. The access edge node contains a service agent unit. Here, the service agent unit manages and controls the service agent. Each service agent, on the one hand, corresponds to one service provider domain, and on the other hand, a virtual local area network (VLAN) on the access domain for the service provider domain. Manage and control Network). Each time the user domain wants to communicate with one selected service provider domain, a service request related message is sent to the access edge node. Service request related messages contain information that identifies one service provider domain and one user domain. The access edge node determines whether a service agent corresponds to the service provider domain identified in the service request related message. If one service agent corresponds to the service provider domain identified in the service request related message, it creates a service binding for the received service request related message. Service bindings identify a service agent, user domain information, and access domain transfer primitives. The access node that provides the connection to the requesting user domain then receives information that the service binding has been created. Then, the aggregate processing of data traffic related to the service request related message is executed on the access domain according to the created service binding. The following paragraphs describe in more detail how service agents, service bindings, access edge nodes, and access nodes are assembled to aggregate data traffic on the access domain. The expression "data traffic" is used throughout this specification with respect to messages and information transferred over a data network.
In order to understand the present invention and the mechanism of the present invention, FIG. 2 will be described. FIG. 2 is a schematic view illustrating the network 200 in which the present invention is incorporated. The schematic of Network 200 has been simplified for clarity purposes. The various elements depicted are grouped by similar functions and do not represent network entities in a positional diagram. However, each group with similar functions typically corresponds to a physical network entity with a particular function, located scattered across the network 200. The schematic of network 200 includes user domain 110, access domain 115, network service provider 140, and application server 150. The access domain 115 includes an access node 120, an access network 130, an access edge node 160, and a regional network 135. A comprehensive description and examples of each element are provided in the following paragraphs with reference to Figure 2.
The network 200 corresponds to one or more data networks that communicate with each other. In this way, the network 200 can be operated by one or more operators. Data networks are typically supported by a large number of operable entities and / or a large number of operational organizations, so it is not possible to clarify how these entities and organizations make communication successful. Required. For this reason, data networks are typically open system interconnect models (OSI model: Open System Interconnection). It will be explained in detail using model). The OSI model clarifies the network framework for executing protocols within seven layers. Each of these seven layers is in the order shown below. 1) Physical layer; 2) Data link layer; 3) Network layer; 4) Transport layer; 5) Session layer; 6) Presentation layer; 7) Application layer. Each layer corresponds to possible aspects and contracted behavior when transferring data over a data network. Using the OSI model to represent the network 200 of the invention, some of the various protocols used and / or supported by the network of the invention are layered as follows: Can be done. Layer 2: Ethernet®, Asynchronous Transfer Mode (ATM) Layer 3: Internet Protocol (IP) version 4, Internet Protocol (IP) version 6 Layers 4 and 5: Transmission Control Protocol (TCP), User Datagram Protocol (UDP) Layers 6 and 7: Various presentation and application protocols that currently exist or will be used in the future The above list of protocols is provided for illustrative purposes only and does not limit the protocols supported by the present invention.
Next, the access domain 115 will be described. Access domain 115 can be summarized as a means of providing end-to-end connectivity between user domain 110, network service provider 140, and application service provider 150. Access domains include access node 120, access network 130, regional network 135, and access edge node 160. Thus, the access domain 115 is not itself an entity, but rather a collection of components. This set of components, whether direct or indirect, behaves as a domain to provide a connection when connected to each other. Therefore, this name is called "access domain". Thus, the representation of the current access domain 115, which includes only one access node 120, one access network 130, one access edge node 160, and one regional network 135, is such that such an entity is single within the access domain. It is clear that only one of those entities is represented, not for the purpose of clarification. The following paragraphs provide a more detailed description of the various components of the access domain.
Access node 120 includes an access gateway (not shown) and represents the first component of access domain 115. Typically, the access node 120 asks an access provider that allows connection to the access network 130 of the user domain 110, for example, whether it is fixed or pay-as-you-go. Such connections are possible using a variety of media and technologies. Media that can be used include cables, landlines, and mobile phones. Available technologies include Integrated Services Digital Network (ISDN), Asymmetric Digital Subscriber Line (ADSL), and WiMax (Worldwide Interoperability for Microwave). Access) is an example. However, it should be noted that the present invention is not limited to those media or technologies. Similarly, although only three access nodes are depicted in the figure, it should also be noted that network 200 potentially contains hundreds or thousands of access nodes.
The access domain also includes the access network 130 and the regional network 135, which will be discussed together below. The primary function of the access network 130 and the regional network 135 is to provide end-to-end, independent forwarding between the access node 120, the network service provider 140, and the application service provider 150. The access network 130 and the regional network 135 are networks that play the following roles. Its role is to aggregate, switch, and route downstream and upstream data traffic. The access network 130 can preferably use Ethernet®, or other similar protocol, corresponding to Layer 2 of the OSI model. However, it is not limited to the protocol corresponding to layer 2 of the OSI model. Access network 130 can favorably support IPv4 and / or IPv6. Regional Network 135 preferably supports Ethernet® and / or IP and MPLS, and supports other Layer 3 protocols possible. In addition, the access network 130 and the regional network 135 can be operated and / or managed by one or more different operators.
Through a strong coupling of their traffic engineering capabilities through the access edge node 160, the access network 130 and the regional network 135 are end-to-end quality of service (QoS). Service) can be provided. The role of Access Edge Node 160 is to create, manage, and host service agents 170 and service bindings (not shown in Figure 2 but depicted in Figure 4). Each service agent 170 corresponds to one service provider domain (140 or 150) and manages and controls VLANs on access network 130 for the corresponding service provider domain. The expression "service binding" refers to the binding between the user domain 110 and one network service provider domain 140, or between the user domain 110 and one application service provider domain 150. The concept of service agents and service bindings and access edge nodes are described in more detail in Figures 4, 5a, and 5b.
Next, the user domain 110 will be described. The user domain relates to an access domain 115 for handling end-to-end communication between the user domain 110 and the network service provider 140, and between the user domain and the 110 application service provider 150. It should be noted that in this description, the term "domain" refers to one or more network components with similar functional characteristics. Thus, in the present invention, the expression "user domain" refers to an independent computer, a local network of computers physically or wirelessly connected through a router, a mobile phone, or a personal digital assistant (PDA). Digital Refers to Assistant) or any other device that can communicate data over a network, such as Network 200. In addition, the expression "user domain" is intended to include multiple data traffic sessions that occur at the same time. Multiple simultaneous data traffic sessions are performed by multiple devices through a single user port. For example, users can simultaneously access different applications and network services such as Internet connectivity and video conferencing and TV programming. The user can then use one or more devices to access simultaneously through the user domain provided in the VLAN or through one single user port, referred to here as the "user domain". ..
Network service provider 140 represents an entity that uses access domain 115 to provide IP address assignments and connections to other networks, and to provide and deliver specific applications. For data traffic with user domain 110, the network service provider 140 typically owns an IP address, using, for example, identification based on RADIUS (Remote Authentication Dial-In User Service), and IP address in user domain 110. To assign. In addition, if requested and / or required, Network Service Provider 140 provides user-level authentication and authorization.
The application service provider 150 uses the access domain 115 to deliver and deliver the application to the end users of the user domain 110. Examples of such applications include games, video on demand, video conferencing, and many other possible applications. However, it is the access domain 115 that assigns the IP address to the user domain 110 on behalf of the application service provider. If requested, application service provider 150 can also authenticate at the user level and, if necessary, authorize. In the above description, the terms "service provider" and "service provider domain" are used instead to represent both the network service provider 140 and the application service provider 150 at the same time. The expression "service provider" may also refer to one of network service provider 140 or application service provider 150.
Next, FIG. 3 will be described. FIG. 3 is a simplified flowchart of a method of collecting data traffic according to the present invention. This method aggregates data traffic on the access domain 115. Access domain 115 forwards data traffic between multiple network service providers 140, multiple application service providers 150, and multiple user domains 110. The method is optionally initiated by step 300 for building multiple service agents on access domain 115. However, it should be noted that step 300, which builds multiple service agents, is not performed every time, but when the access edge node 160 is deployed in the access domain 115. The method then begins at step 310. In step 310, the service request related message is received on the access edge node 160. Service request related messages identify one service provider and one user domain. Service request related messages occur, for example, through access by an identified user domain to an identified service provider's web page. Next, the method continues to step 320. In step 320, one of the constructed service agents identifies whether it corresponds to the identified service provider 140 or 150. Then, this method executes step 330. In step 330, it is determined whether a service binding is required. If step 330, which determines the need for service binding, is true, the method follows step 340. In step 340, a service binding is created for the received service request related message. The method then continues to step 350. In step 350, the service to access node 120, which is responsible for providing the connection to the user domain identified in the service request related message. Communicate information that you have created a bisbinding. In this way, data traffic received from the user domain identified and addressed to the identified service provider in the service request related message is aggregated according to the service binding created on the access domain. Information is propagated to access node 120. The method then continues to step 360. In step 360, data traffic received and forwarded on the access edge node for the identified user domain and service provider, or access node 115, is aggregated according to the service binding created. If it is determined in step 330 that no service binding is required, the method continues to step 370. In step 370, it is determined whether the service binding for the received service request related message already exists. If the service binding already exists as a result of the decision in step 370, the method performs step 350. In step 350, the service binding information existing on the access node 120 is transmitted. Instead of the results described above, if the result of the decision in step 370 is false, the method continues to step 380. In step 380, the data traffic corresponding to the received service request related message is forwarded without being aggregated on the access domain 115. Data traffic received at the edge node or access node and forwarded on the access domain 115 is aggregated according to the service binding created. If it is determined in step 330 that no service binding is required, the method continues to step 370. In step 370, it is determined whether the service binding for the received service request related message already exists. If, as a result of the decision in step 370, the service binding already exists, the method performs step 350. In step 350, the service binding information existing on the access node 120 is transmitted. Instead of the results described above, if the result of the decision in step 370 is false, the method continues to step 380. In step 380, the data traffic corresponding to the received service request related message is forwarded without being aggregated on the access domain 115. Data traffic received at the edge node or access node and forwarded on the access domain 115 is aggregated according to the service binding created. If it is determined in step 330 that no service binding is required, the method continues to step 370. In step 370, it is determined whether the service binding for the received service request related message already exists. If, as a result of the decision in step 370, the service binding already exists, the method performs step 350. In step 350, the service binding information existing on the access node 120 is transmitted. Instead of the results described above, if the result of the decision in step 370 is false, the method continues to step 380. In step 380, the data traffic corresponding to the received service request related message is forwarded without being aggregated on the access domain 115.
As mentioned earlier, service bindings relate to forwarding relationships. A forwarding relationship is built between one user domain and one service provider and directly affects one service agent 170 of access node 120 and access edge node 160 that provides the connection. Conceptually, creating a service binding corresponds to adding the identified user domain to the VLAN corresponding to the service provider domain on the access domain. In this way, each service binding represents a tradable business entity. A tradable business entity ensures that the corresponding service is delivered between a particular user port in the user domain and a particular provider port in the service provider, maintaining proper state and QoS. Service bindings are created, managed, hosted, and exist in conjunction with Service Agent 170 within the Access Edge node.
Service agents and service bindings are created, managed, and hosted within the access edge node. Therefore, Fig. 2 and Fig. 4 will be described at the same time. FIG. 4 is a schematic diagram of an access edge node according to the disclosure of the present invention. Access edge nodes are made up of multiple elements to allow them to play the role of creating, managing, and hosting service agents and service bindings. Due to the location of the access edge node within the access domain 115, in order to communicate with the access network 130 and access node 120 of the access domain 115, the access edge node includes an I / O unit containing the access domain I / O unit 410 Includes. It is also the access domain I / O unit 410 that receives the service request related message 420. The I / O unit of the access edge node 160 also includes a network / application service provider domain I / O unit 430 for communicating with the network service provider 140 and the application service provider 150 on the regional network 135. Further, the access edge node 160 includes a service agent unit 440 and a control unit 450, and may further include a translation table 460, a transfer unit 470, and a coordination unit 480.
The service agent unit 440 is composed of a service agent management / control unit 442 and a service binding hosting unit 444. The service agent unit 440 holds the information of the existing service agent 170 in the service agent management / control unit 442. The service agent management and control unit 442 is then responsible for creating and managing the service binding 446. Therefore, the service agent management / control unit 442 determines when a new service binding 446 is requested or deleted, and subsequently creates / deletes the service binding 446. Service agent management and control unit 442 is also responsible for adding / removing user devices to existing service bindings. In addition, the service agent management and control unit 442 is responsible for ensuring the synchronicity of service binding 446 related information with the access nodes communicating with each other. The service agent management / control unit 442 has MPLS (Multi) in the access network 130. If a route secured by Protocol Label Switching) is requested, it is also responsible for creating such a route. The description given with Figures 7 and 8 provides a comprehensive description of the various messages used by the service agent management and control unit to fulfill different responsibilities.
Next, FIGS. 4 and 5a will be described at the same time. FIG. 5a is a chart illustrating the items of the service agent management / control unit 442. With the exception of the first row, which is the header row, each row in FIG. 5a illustrates items in several service agents 170 that are managed and controlled by the service agent management and control unit 442. Each column in Figure 5a corresponds to the specific information held by the service agent management and control unit 442 for each service agent 170. The first column shows the identification of the service agent 170. The identification is typically the service agent identifier of the corresponding service agent, or a number. In a preferred embodiment of the invention, each service agent within the access edge node has a unique service agent identifier and corresponds to one particular service provider domain 140 or 150. The second column shows the identification of a particular service type for the corresponding service agent. For example, if one service provider domain 140 or 150 provides multiple services, each service provided is associated with a different service type due to the differentiation between the various services in the service provider domain. The third column identifies the preferred or required quality of service (QoS). The quality of service (QoS) described above is the quality of service (QoS) required to properly forward data traffic for the associated service type and service provider domain described above. Examples of QoS criteria include delay, bit error rate, bandwidth, and recommended protocols. The fourth column points to the ports used within the regional network to communicate with the corresponding service provider domain. In addition to this item, a service to create added service agents and remove service agents that are no longer needed Sagent management and control unit 442 includes sufficient logical software and hardware. It should be noted that although the items of the service agent management / control unit are represented in the form of a table in Fig. 5a, such items are not limited to those shown in Fig. 5a. The service agent management and control unit can also consist of a relational database, hard-coded components, microprocessors, programming libraries, and so on.
Next, FIGS. 4 and 5b will be described at the same time. FIG. 5b is a chart illustrating the items of the service binding hosting unit in the disclosure of the present invention. With the exception of the header line, each line in Figure 5b illustrates some service binding 446 items hosted within the service binding hosting unit 444. Each column in Figure 5b corresponds to specific information hosted within the service binding hosting unit 444 for each service binding 446. The first column represents the identification of the corresponding service agent, for example by using the service agent identifier of the service agent. The second column identifies the service type, as described for Figure 5a. The other columns represent the forwarding primitives for data traffic related to service bindings. More specifically, the third column is the MAC address of the user domain (Media Access Controll). address) is identified. The fourth column consists of identifying the ports used by the user domain on the access node that provides the connection. The fifth column corresponds to the local network indefinite identifier used by the user domain and may contain, for example, potential or explicit VLAN information. The sixth column shows the virtual MAC address of the access node that provides the connection to the user domain. Thus, to provide data traffic between one user domain and one service provider domain 140 or 150, each service binding 446 has one service agent, one user domain, and one access node. To connect with. It should be noted that although the items of service binding hosting unit 444 are represented in the form of a table in Figure 5b, such items are not limited to those shown in Figure 5b. The service binding hosting unit can also consist of a relational database, hard-coded components, microprocessors, programming libraries, and so on.
In addition, the service binding hosting unit can also include a seventh additional item. This seventh item contains an IP address that uniquely identifies the user domain or user device by the item. Its unique IP address is, for example, DHCP (Dynamic Host Configuration) using a broadcast mechanism that runs in preference to service request messages. It is provided to a user domain or user device by an access edge node through a protocol such as Protocol). Thus, the combination of a unique IP address of a user domain or user device with a service agent identifier represents a concise and reliable way to quickly relate incoming messages to the appropriate service bindings. Typically, once a service binding is created, that information is propagated to the access node and data traffic is aggregated on the access domain according to the service binding. The aggregated data traffic received at the access edge node is then decomposed using the information provided by the service binding hosting unit in preference to forwarding to the corresponding service provider domain. In particular, if the access domain is an Ethernet network, the service agent identifier is provided, for example, in a field known as a VLAN tag for unicast, multicast, and broadcast messages. On the other hand, at this time, the IP address of the user domain or the user device is provided in the IP message embedded in the Ethernet message. Based on the service agent identifier provided in the VLAN tag field of the Ethernet message, and based on the IP address provided in the embedded IP message, the service agent unit 440 decomposes the data traffic and of the user. You can ensure that data traffic is forwarded to the corresponding service provider domain, including the required information about the source user domain, such as MAC information and local network context.
Returning to FIG. 4, when the access edge node control unit 450 receives the service request-related message 420, it is responsible for deciding whether the service request-related message 420 corresponds to one service agent. To do so, control unit 450 queries service agent management and control unit 442, which determines whether one service agent 170 corresponds to the service provider domain identified in service request related message 420. If one service agent 170 corresponds to the service provider domain identified in service request related message 420, control unit 450 should create service binding 446 for the received service request related message. Give instructions to the management / control unit 442. Creating a service binding 446 for the received service request related message 420 involves adding an entry to the service binding hosting unit 444 as follows: -The service agent ID (first column) corresponds to the service agent identifier for the service agent corresponding to the requested service provider domain. -The user's MAC information is the MAC address of the user device. -The user port on the access node is the identification of the port on the access node that provides the connection, and the user device is concatenated with the access node that provides the connection. -The local network context corresponds to the indefinite identifier provided in the "VLAN tag" labeled field of the Ethernet message received from the user device, and the indefinite identifier corresponding to the local user domain identifier. -The access node MAC is the virtual MAC address of the access node that provides the connection from which the service request related message related to it was received.
The control unit 450 then conveys information that the service binding 446 has been created to the access node that provides the connection to the user domain identified in the service request related message. At this time, the information is transmitted through the service binding related message 490 sent by the access domain I / O unit 410. If the service binding for the service request related message 420 already exists, the control unit 450 conveys information through the service binding related message 490 that the service binding exists on the access node providing the connection.
The control unit 450 also cooperates with the translation table 460. Each service agent 170 in the service agent management and control unit is uniquely identified by the service agent identifier, so in the translation table, the service agent identifier corresponding to the service agent 170 and the corresponding service provider domain (140 or 150). It is essential to keep the mapping between). In this way, when the access domain input / output unit 410 receives data traffic having a target address corresponding to the virtual MAC address for the access edge node 160 and a VLAN tag corresponding to one service agent identifier, the access edge To quickly translate the node's virtual MAC address to the destination service provider domain address (140 or 150 address) that corresponds to the service agent identifier provided in the VLAN tag, control unit 450 queries translation table 460. ..
In addition, the control unit 450 transfers to the transfer unit 470 to determine whether the data traffic received by the access domain I / O unit 410 is forwarded directly to the service provider domain I / O unit without any modification. Inquire. Finally, the control unit 450 also cooperates with the adjustment unit 480. Coordinating unit 480 was pointed to and / or requested by the corresponding service agent 170 whether it received data traffic on either the access domain I / O unit 410 or the network / application service provider domain I / O unit 430. As such, keep upstream / downstream traffic in order, mark, and remark traffic.
Next, FIG. 6 will be described. FIG. 6 is a schematic view of one access node according to the disclosure of the present invention. For locational reasons within the access domain 115, the access node 120 includes an access domain I / O unit 610 to communicate with the access network 130 and the access edge node 160 of the access domain 115. The access node 120 also includes a user domain I / O unit 620 to communicate with the user domain 110. The message type received by the access domain I / O unit 610 is service binding related message 490. The service binding related message 490 is generated by the access edge node 160 and sent on the access network 130. An example of service binding message 490 is provided in the description for Figures 7 and 8.
The access node 120 can receive and process a plurality of service binding related messages 490. The service binding related message 490 comes from the access network 130 and is received by the access node 120 through the access domain I / O unit 610. Upon receiving the service binding-related message 490, the access domain I / O unit forwards the received service binding-related message 490 to the control unit 630. The control unit 630 extracts the contact of the service binding related message 490 and determines whether there is any processing to be performed. The example service binding related message 490 is information about creating a new service binding. As mentioned earlier, if the access edge node 160 determines that a new service binding is being requested, it will continue to create the service binding and go to the access node that is providing the connection to the requesting user domain. Information that the service binding has been created is transmitted. The service binding related message 490 used in this special case is called ADD_SB (add servic binding). The ADD_SB message contains information about the service binding sent from the access edge node 160 to the access node 120 and created. The information contained in the ADD_SB message is then incorporated into the collective unit 680 of access node 120.
One of the various responsibilities of the collective unit 680 is the hosting of service binding related information. Service binding related information includes identification on the port of the access node that receives specific service binding information and service request related messages (in the form of service agent attributes and service types) and the local network context of the user domain.
The access node 120 further processes the received data traffic transmitted from / to the user domain and provides the user domain with a connection service to the access network 130. Therefore, the access node 120 further includes a translation table, a 650, a transfer unit 660, a coordination unit 670, and an aggregate unit 680. By doing so, on the access node 120, the data traffic received by either the user domain I / O unit 620 or the access domain I / O unit 610 is also forwarded to the control unit 630. Control unit 630 works with translation table 650. Service binding of service agent unit 440 Each service binding stored in hosting unit 444 is identified by a combination of parameters (service agent attribute, service type, user device MAC address, and access node virtual MAC address). Therefore, it is essential to maintain the mapping between the service agent attribute corresponding to the service agent 170 and the corresponding service provider domain (140 or 150) in the translation table 650. In this way, when the access domain I / O unit 610 receives data traffic having a target address corresponding to the virtual MAC address of the access node 120, the control unit is used to correspond to the user domain MAC address and the local identifier, respectively. The 630 queries the translation table 650 to quickly translate the destination address and VLAN tag. Such conversion is required because the user domain information is not carried on the access domain between the access edge node 160 and the access node 120. In this way, one embodiment of the present invention makes it possible to aggregate data traffic on the access domain without interruption from the viewpoint of the user domain.
In addition, to determine if the data traffic received by the access domain I / O unit 610 or user domain I / O unit 620 is forwarded directly to the corresponding user domain 110 or access network 130 without any modification. , The control unit 630 queries the transfer unit 660. Finally, the control unit 630 also works with the coordinating unit 670. Interaction with Coordinating Unit 670 is required when downstream / upstream traffic needs to be ordered, marked, and remarked, as pointed out within the attributes of the service binding. ..
Next, FIG. 7 will be described. FIG. 7 is a flowchart of some messages exchanged between the access node 120 and the access edge node 160. These messages carry information about management and traffic manipulation between the access node 120 and the access edge node 160. The messages depicted in Figure 7 should be read as a list of possible message examples for exchanging information between each access node 120 and access edge node 160, rather than being read sequentially. The messages exchanged on FIG. 7 are instead referred to as "service binding related messages 490" through the above description. The message list depicted in Figure 7 should not be read as a thorough and complete message list exchanged between Access Node 120 and Access Edge Node 160, but as an example of a message.
The first message depicted in Figure 7 is called ALIVE Message 700. ALIVE message 700 is sent from access edge node 160 to one of access node 120 to convey information that it is currently considered inactive by access edge node 160. For the access node 120 that has received the ALIVE message 700, the reception of the ALIVE message 700 described above causes the transmission of the SYNC message 705 to the access edge node 160. The SYNC message 705 can be used to notify that the local configuration stored in the collective unit 680 stored on the source access node 120 has been lost or out of date. The SYNC message 705 notifies the access edge node 160 that the configuration of the source access node 120 needs to be rebuilt. SYNC message 705 is typically followed by CONFIG-AN message 710. CONFIG-AN message 710 contains the information needed to rebuild its local configuration on the access node 120 that received the message. The CONFIG-AN message is followed by a CONFIG-AN ACK (acknowledgement) message or a CONFIG-AN NACK (no acknowledgment) message 715 to ensure that the CONFIG-AN message 710 was received correctly.
Further describing FIG. 7, another message type exchanged between the access node 120 and the access edge node 160 is ADD_SB message 720. The ADD_SB message 720 allows access edge node 160 to communicate to access node 120 that receives the message that it has added a new service binding to its local configuration or updated an existing service binding. Become. ADD_SB message 720 is followed by ADD_SB ACK (acknowledgement) message or ADD_SB NACK (no acknowledgment) message 725.
Another message type exchanged is specifically about service binding for IPv4. The message ADD_UD_IPv4 730 notifies the access node 120 receiving the message that it is adding or updating a user device to an existing service binding for IPv4. The ADD_UD_IPv4 message is followed by an ADD_UD_IPv4 ACK (acknowledgement) message or ADD_UD_IPv4 NACK (no). acknowledgement) Message 735 follows. Another message about IPv4 service binding generated by access edge node 160 is REM_UD_IPv4 message 740. The REM_UD_IPv4 message 740 allows the access edge node 160 to notify the access node 120 that receives the message that it is removing the user device for an existing service binding for IPv4. Similar to the previous message, REM_UD_IPv4 message 740 is followed by a response message from access node 120 in the form of REM_UD_IPv4 ACK or REM_UD_IPv4 NACK message 745.
A set of messages for IPv6 service binding is provided, as well as messages for IPv4 service binding. The message ADD_UD_IPv6 750 notifies the access node 120 receiving the message that it is adding or updating a user device to an existing service binding for IPv6. The ADD_UD_IPV6 message is followed by the ADD_UD_IPV6 ACK (acknowledgement) message or the ADD_UD_IPV6 NACK (no). acknowledgement) Message 755 follows. Another message about IPv6 service binding generated by access edge node 160 is REM_UD_IPv6 message 760. The REM_UD_IPv6 message 760 allows the access edge node 160 to notify the access node 120 that receives the message that the user device will be removed for the existing service binding for IPv6. Similar to REM_UD_IPv4 message 740 above, REM_UD_IPv6 message 760 is followed by a response message from access node 120 in the form of REM_UD_IPv6 ACK or REM_UD_IPv6 NACK message 765.
Another message type sent from the access edge node 160 to the access node is REM_SB message 770. REM_SB message 770 notifies access node 120 that the service binding identified in the message will be removed from the local configuration. When the removal of the service binding is complete on access node 120, a REM_SB_ACK or REM_SB_NACK message is used to confirm that the removal of the notified service binding from the local settings is complete, or to notify that it did not complete properly. The 775 is sent from the access node to the access edge node 160. Upon receiving the various messages listed above from the access edge node 160, the access node 120 that receives the message makes the necessary updates to the local configuration of the access node 120 to synchronize with the active service binding. It is expected.
Next, FIG. 8 will be described. Figure 8 shows a table showing the fields of the message in Figure 7. Message format 800 contains the fields depicted in the box, indicating the number of bytes corresponding to the bottom of the box. The first field is version field 805. The version field indicates the version used in the message. The corresponding reply message should be sent using the same version of the protocol. The second field is the message flag field 810. The availability of one of the fields is indicated by using bit 0 of the byte, where 1 indicates that the message is a request, while 0 indicates that the message is a reply. The third field is the message length field 815. The message length field 815 indicates the total length of the message consisting of all the fields defined here except the authentication code field 850. The field that follows is timestamp 820. Timestamp field 820 is used to indicate when the message was sent. The timestamp field uses Coordinated Universal Time, which is precisely defined in seconds. The service agent identifier 825 field specifies the attributes of the service. The application instance identifier 830 in the service agent uniquely specifies the application instance for each service binding. The message identifier field 835 is used by the requester to correlate the reply message with its corresponding request message. Next is the command count field 840. The command count field 840 is used to indicate the number of commands specified in the command list. Command list field 845 represents the command list. Each command should follow the following format: The format is 2 bytes related to the command type However, 2 bytes have a variable number of bytes related to the command data with respect to the command data length. The table below provides additional information about possible command types, command data lengths, and command data. Finally, authentication code field 850 is used to authenticate the message.<tables num="1"><img file="JP4698684B2_D0001.tif" /></tables><img file="JP4698684B2_D0002.tif" /><img file="JP4698684B2_D0003.tif" /><img file="JP4698684B2_D0004.tif" />
To help you understand the table above, a list of acronyms and their definitions is provided below. AEN: access edge node ACK: acknowledgment ADD_AUTH_MAC: Add / update an authorize MAC ADD_AUTH_SB: Add / update an authenticated service binding ADD_PROFILE: Add / update a rate limiting profile ADD_SB: Add / update a service binding ADD_UD_IPv4: Add / update a device to an existing service binding for IPv4 user device to an existing service binding for IPv4) ADD_UD_IPv6: Add / update a user device to an existing service binding for IPv6 AN: access node CBS: Committed Burst Size CIR: Committed Information Rate CONFIG_AN: Configure Access Node EBS: Excess Burst Size JOIN_AUTH_IPv4: Join / re-join IPv4 for IPv4 multicast groups for authenticated user devices multicast group for authenticated user device) JOIN_AUTH_IPv6: Join / re-join IPv6 multicast group for authenticated user device JOIN_IPv4: Join / re-join IPv4 multicast group JOIN_IPv6: Join / re-join IPv6 multicast group LEAVE_AUTH_IPv4: Leave IPv4 multicast group for authenticated user device LEAVE_AUTH_IPv6: Separation of IPv6 multicast groups for authenticated user devices (Leave) IPv6 multicast group for authenticated user device) LEAVE_IPv4: Leave IPv4 multicast group LEAVE_IPv6: Leave IPv6 multicast group MAC address: MAC address (Media Access Control address) PBS: Peak Burst Size PIR: Peak Information Rate REM_AUTH_SB: Remove an authenticated service binding REM_PROFILE: Remove a rate-limiting profile REM_SB: Remove a service binding REM_UD_IPv4: Remove a user device from an existing service binding for IPv4 REM_UD_IPv6: Remove a user device from an existing service binding for IPv6 SND_AND: Send frame on Access Network Domain SND_ETH_D: Send frame downstream SND_ETH_U: Send frame upstream SND_UND: Send frame on the specified user port toward the User Domain)
Although some preferred embodiments of the methods and nodes of the invention are shown in the accompanying drawings and described in the detailed description above, the invention is not limited to the described embodiments and is claimed. It should be understood that various changes, modifications and alternatives are possible that do not depart from the technical thinking of the invention described and defined in the scope.
<figref num="1">It is explanatory drawing which shows the prior art example of an IP network.</figref><figref num="2">It is the schematic which illustrates the network in which this invention was incorporated.</figref><figref num="3">It is a simplified flowchart of the method of collecting data traffic according to this invention.</figref><figref num="4">It is the schematic of the access edge node according to the disclosure of this invention.</figref><figref num="5a">It is a figure which illustrated the item of the service agent management | control unit in this invention.</figref><figref num="5b">It is a figure which exemplifies the item of the service binding hosting unit in the disclosure of this invention.</figref><figref num="6">It is the schematic of the access node according to the disclosure of this invention.</figref><figref num="7">It is a flowchart illustrating the message exchanged between an access node and an access edge node according to the disclosure of this invention.</figref><figref num="8">FIG. 5 is a chart showing various fields of messages exchanged between access nodes and access edge nodes according to the disclosure of the present invention.</figref>
13 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| WO2004102890A1 | Cites | World Intellectual Property Organization (WIPO) |
| JP2004304574A | Cites | Japan |
| JP2004187282A | Cites | Japan |
82 members in 10 offices
Priority claims19
| Document | Office | Kind | Date |
|---|---|---|---|
| 60651971 | United States of America | – | |
| 65197105 | United States of America | P | |
| 65197105 | United States of America | P | |
| 60674307 | United States of America | – | |
| 67430705 | United States of America | P | |
| 67430705 | United States of America | P | |
| 11316934 | United States of America | – | |
| 31693405 | United States of America | A | |
| 31693405 | United States of America | A | |
| 2006050309 | International Bureau of the World Intellectual Property Organization (WIPO) | W | |
| 2006050309 | International Bureau of the World Intellectual Property Organization (WIPO) | W | |
| 2005316934 | – | – | – |
| 2005651971 | – | – | – |
| 2005674307 | – | – | – |
| 2006050309 | – | – | – |
| US20050316934 | – | – | – |
| US20050651971P | – | – | – |
| US20050674307P | – | – | – |
| WO2006IB50309 | – | – | – |
Members82
| Document | Office | Kind | |
|---|---|---|---|
| CA2594429A1 | Canada | A1 | |
| CA2594432A1 | Canada | A1 | |
| US2006182123A1 | United States of America | A1 | |
| US2006182146A1 | United States of America | A1 | |
| US2006184645A1 | United States of America | A1 | |
| US2006184694A1 | United States of America | A1 | |
| US2006184695A1 | United States of America | A1 | |
| WO2006085233A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2006085234A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2006085286A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2006085290A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2006085292A1 | World Intellectual Property Organization (WIPO) | A1 | |
| CA2604234A1 | Canada | A1 | |
| WO2006114713A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2006251055A1 | United States of America | A1 | |
| WO2006085233A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO2006114713A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO2006085234A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1849265A1 | European Patent Office (EPO) | A1 | |
| EP1849266A1 | European Patent Office (EPO) | A1 | |
| EP1849267A1 | European Patent Office (EPO) | A1 | |
| EP1849271A2 | European Patent Office (EPO) | A2 | |
| EP1849272A2 | European Patent Office (EPO) | A2 | |
| EP1878171A2 | European Patent Office (EPO) | A2 | |
| CN101120544A | China | A | |
| CN101120545A | China | A | |
| CN101120546A | China | A | |
| CN101120553A | China | A | |
| CN101120554A | China | A | |
| CN101164302A | China | A | |
| JP2008530881A | Japan | A | |
| JP2008530882A | Japan | A | |
| JP2008530889A | Japan | A | |
| JP2008530891A | Japan | A | |
| JP2008537365A | Japan | A | |
| JP2008538885A | Japan | A | |
| EP1849266B1 | European Patent Office (EPO) | B1 | |
| EP1849267B1 | European Patent Office (EPO) | B1 | |
| AT418212T | Austria | T | |
| AT421206T | Austria | T | |
| ATE418212T1 | Austria | T1 | |
| ATE421206T1 | Austria | T1 | |
| DE602006004307D1 | Germany | D1 | |
| EP1849272B1 | European Patent Office (EPO) | B1 | |
| DE602006004845D1 | Germany | D1 | |
| EP1849265B1 | European Patent Office (EPO) | B1 | |
| EP1849271B1 | European Patent Office (EPO) | B1 | |
| AT424678T | Austria | T | |
| AT425612T | Austria | T | |
| AT425617T | Austria | T | |
| ATE424678T1 | Austria | T1 | |
| ATE425612T1 | Austria | T1 | |
| ATE425617T1 | Austria | T1 | |
| DE602006005468D1 | Germany | D1 | |
| DE602006005620D1 | Germany | D1 | |
| DE602006005621D1 | Germany | D1 | |
| ES2318730T3 | Spain | T3 | |
| US7660253B2 | United States of America | B2 | |
| BRPI0607334A2 | Brazil | A2 | |
| BRPI0607337A2 | Brazil | A2 | |
| CN101120544B | China | B | |
| US7792996B2 | United States of America | B2 | |
| US7801039B2 | United States of America | B2 | |
| CN101120546B | China | B | |
| CN101120554B | China | B | |
| CN101120553B | China | B | |
| JP4583455B2 | Japan | B2 | |
| JP4583456B2 | Japan | B2 | |
| US7881198B2 | United States of America | B2 | |
| JP4638511B2 | Japan | B2 | |
| JP4696131B2 | Japan | B2 | |
| JP4698684B2This record | Japan | B2 | |
| US8077619B2 | United States of America | B2 | |
| BRPI0610375A2 | Brazil | A2 | |
| JP5133873B2 | Japan | B2 | |
| EP1878171B1 | European Patent Office (EPO) | B1 | |
| CA2594432C | Canada | C | |
| CA2604234C | Canada | C | |
| CA2594429C | Canada | C | |
| CN104717118A | China | A | |
| CN104717118B | China | B | |
| BRPI0607334B1 | Brazil | B1 |
15 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 4698684
- Publication, DOCDB
- 4698684
- Publication, EPODOC
- JP4698684B
- Application
- 2007554685
- Application, DOCDB
- 2007554685
- Application, EPODOC
- JP20070554685
Titles2
- Japanese
- アクセスドメイン上でデータトラフィックを集合する方法と、本方法に関するノード
- English
- How to collect data traffic on the access domain and nodes related to this method
Classification
- CPC, 9
- H04L47/15
- H04L47/781
- H04L47/805
- H04L47/825
- H04L63/08
- H04L47/70
- H04L67/563
- H04L67/566
- H04L67/63
- IPC, 1
- H04L12 56
