Patent Application
20080232369
The present invention generally relates to communication systems and methods and, more particularly, to mapping mechanisms and techniques for segregating access networks in communication systems.
Communication systems continue to grow and evolve. Convergence between different types of communication systems, e.g., Internet Protocol (IP), connection-based voice communications, and the like, is advancing rapidly. Recently the phrase “Next Generation Network” (NGN) has been used to describe various activities associated with this evolution. As defined by the International Telecommunications Union (ITU), an NGN is a packet-based network able to provide services (including telecommunication services) and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. NGNs will also likely offer unrestricted access by users to different service providers and will support generalized mobility, which in turn will provide for consistent service provision to end users.
Various standardization groups are working on reaching a consensus regarding the technology considerations which will affect NGN design and implementation. For example, Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) is an ETSI standardization group which focuses on convergence of technologies used in the Internet and other fixed networks. Among other things, TISPAN seeks to provide a modular, subsystem-oriented architecture which facilitates the addition of new subsystems over time to cover new demands and service classes. The TISPAN architecture attempts to ensure that network resources, applications, and user equipment are common to all of the various subsystems to provide for enhanced mobility across, for example, administrative boundaries.
One of the TISPAN subsystems is referred to as the Network Attachment Sub System (NASS). The NASS is responsible for, among other things, handling configuration information, user authentication data, IP address allocation and registering associations between IP addresses allocated to user equipment (UE) and related network location information. These latter two NASS functions, i.e., allocating IP addresses and registering associations, are handled by the Network Access Configuration Function (NACF) and the Connectivity Session Location and Repository Function (CLF), respectively, which are functional entities that are also specified by the NASS portion of the TISPAN standards.
These NASS functional entities interact with another TISPAN subsystem known as the Resource Admission Control Subsystem (RACS) and, of particular interest for the present discussion, with the Access Resource and Admission Control Function (A-RACF) functional entity of the RACS. The A-RACF functional entity, among other things, receives information about the IP address allocated to a particular user and maps that IP allocation to physical resources in the access network. Each A-RACF is, in these exemplary embodiments, associated with a Session Border Controller (SBC). An SBC interacts directly with the network elements that provide communication services to an end user, e.g., Digital Subscriber Line Access Multiplexers (DSLAMs).
An exemplary, conceptual relationship between these NASS functional entities and the RACS functional entities and SBCs is provided as
The NASS and TISPAN standards employ a Global IP Address technique for allowing IP address reuse via multiple domains. The interface specified for communication between the CLF 12 and A-RACFs 14, referred to in these standards as the “e4” interface, contains the Global IP Address as a parameter. For example, when performing an access profile push (e.g., when an IP address has been allocated to a user), the CLF 12 sends a message containing the information elements shown in
One problem associated with this standardized approach to IP address handling is that it presumes that there is a one-to-one relationship between IP addressing zones or realms and the A-RACF servers. Thus there is no information in the “Globally Unique IP Address” information element which would, for example, inform a CLF 12 which one of a number of different A-RACFs 20 within a single IP Addressing zone should receive information associated with a particular profile push or pull, which problem is conceptually illustrated as
Accordingly, it would be desirable to have a mechanism for segregating access networks which avoids the afore-described problems and drawbacks.
According to an exemplary embodiment, a network node includes a processor for transmitting and receiving messages associated with at least one of: a location of user equipment and an IP address allocation to the user equipment, wherein the messages are associated with one of a plurality of access resource and admission control functions (A-RACFs) within an IP addressing zone based upon an identifier, and wherein the one of said plurality of A-RACFs is associated with the user equipment.
According to another exemplary embodiment, a method for communicating in a network includes the steps of transmitting messages associated with at least one of: a location of user equipment and an IP address allocation for the user equipment, wherein the messages are associated with one of a plurality of access resource and admission control functions (A-RACFs) within an IP addressing zone based upon an identifier, and wherein the one of the plurality of A-RACFs is associated with the user equipment.
According to yet another exemplary embodiment, a communication network includes a first server which provides a connectivity session location function (CLF) to register an association between an IP address allocated to a user equipment and network location information, and a plurality of second servers, each of which provides an access resource and admission control function (A-RACF) to verify that bandwidth needed for requested services can be delivered, the plurality of second servers each being associated with a single IP addressing zone, wherein each of the second servers is associated with a different topology zone identifier and further wherein at least some messages transmitted between the first server and the second servers includes both a global IP address information element and one of the topology zone identifiers.
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. In the drawings:
a) illustrates an exemplary relationship between entities associated with two IP addressing zones;
b) and 1(c) depict conventional access profile push and pull messages, respectively;
d) illustrates a problem associated with a lack of cardinality between CLF and A-RACF entities;
The following description of the exemplary embodiments of the present invention refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims.
In order to provide some context within which exemplary embodiments will be better understood, consider the exemplary portion of a communication network illustrated as
To briefly step through the exemplary network structure illustrated in
Of particular interest with respect to the present specification, it will be seen that each A-RACF 34 within the IP addressing zone 20 is assigned to its own topology zone. In this exemplary embodiment, the upper illustrated A-RACF 34 is assigned to topology zone 1 and the lower illustrated A-RACF 34 is assigned to topology zone 2. Within each IP addressing zone, each A-RACF 34 will be uniquely identifiable based on its assigned topology zone identifier. Thus, CLF 22 will be able to route access profile information associated with a CPE 26 in the upper half of the Figure to the A-RACF 34 in topology zone 1 and it will, likewise, be able to route access profile information associated with a CPE in the lower half of the Figure to the appropriate A-RACF 34 in topology zone 2. Similarly, the A-RACFs in other IP addressing zones (not shown in
The assignment of A-RACFs 34 to topology zones as described in the above exemplary embodiment enables networks, methods and nodes according to these exemplary embodiments to correctly route access profile related information and requests to and from A-RACFs without requiring that each A-RACF be assigned to its own IP addressing zone. Thus topology zone identifiers can be provided in either or both of the access profile push and pull messages transmitted between the CLF 22 and the A-RACFs 34 as shown in Tables 1 and 2 below, respectively.
As mentioned above, in some alternative exemplary embodiments, it may not be necessary or desirable to transmit the topology zone identifier in both (or either of) the access profile push message and the access profile pull message as shown in the tables above. For example, in some implementations, the topology zone identifier may only be transmitted with the access profile pull message such that the CLF 22 knows to which A-RACF 34 to send a particular access profile response. Additionally, topology zones may be implemented statically or dynamically as discussed in more detail below.
Moreover, the specific formats or values used for the topology zone identifiers which are provided within these messages may vary. When provided explicitly, the topology zone identifiers can be transmitted as information elements in messages which also include the Global Unique IP identifier information element as well, as also shown in the exemplary tables above. The Global Unique IP identifier information element typically is transmitted as a value which is compliant to the Domain Name System (DNS) naming system whereas, according to one purely illustrative exemplary embodiment, the topology zone identifier will not be formatted as a DNS name.
Thus, based on the foregoing, it will be appreciated that a method for communicating in a network according to an exemplary embodiment can include the steps illustrated in the flowchart of
As described above, implementation of a topology zone identifier or the like according to these exemplary embodiments can impact, among other things, the CLF 22, A-RACF 34 and the SBC 32 entities within a communication network. Structurally, the CLF 22, A-RACF 34 and SBC 32 can, for example, each be implemented in hardware and software as servers. For example, as shown generally in
While
Similarly, an A-RACF network node 400 operates to verify that bandwidth needed for services requested by particular CPE 26 can be delivered and, therefore, can transmit and receive messages over an e4 interface which include information associated with at least one of: initial gate setting, list of allowed destinations, uplink subscribed bandwidth, downlink subscribed bandwidth, QoS profile information, transport service class, media type, maximum priority and requester name. Likewise, an SBC network node 400 operates as a gateway device between the end user and the network and can transmit and receive messages including information associated with a location information query for, e.g., 911 purposes. In response to this query, the CLF 22 can provide the SBC 32 with the topology zone of the appropriate A-RACF 34 from which it can request a reservation.
As mentioned earlier, the assignment of topology zones according to exemplary embodiments may be static or dynamic. For example, a CLF 22 can have a list stored in its memory of entities which are permitted to connect thereto, which list may include, among other attributes, a statically configured topology zone assignment based on IP address ranges. Alternatively, when an A-RACF 34 communicates with the CLF 22, the message can indicate its intrinsic knowledge that it is permitted to connect to that particular CLF 22 along with the provision of a dynamically assigned topology zone identifier. In part, implementation of static or dynamic topology zone assignment may depend upon how a network is deployed. For example, although the illustrative example of
Although profile access push and pulls are described above as examples of messages which may include, or be affected by, topology zone identifiers according to exemplary embodiments, those skilled in the art will appreciate that other messages may also include, or be affected by, topology zone identifiers. For example, IP release indications are used by the NASS to report loss of IP connectivity. To report this information, the CLF 22 can send a message to the appropriate A-RACF 32 based upon its knowledge of the appropriate topology zone. The message, an example of which is provided in Table 3 below, may also include the topology zone identifier.
The foregoing description of exemplary embodiments provides illustration and description, but it is not intended to be exhaustive or to limit the invention to the precise form disclosed. For example, topology zones and the like as described above with respect to the exemplary embodiments can adapt and be added, e.g., for scalability reasons. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The following claims and their equivalents define the scope of the invention.
