Network model describing resource dependencies
6.1 Different types of resources and their relationships
6.1.1 Physical resources and their relationships . . . . 114 6.1.2 Functional resources and their relationships . . . . 115 6.1.3 Procedural resources and their dependencies . . . . 117 6.1.4 Inter-layer relationships . . . . 118 6.2 Contributions: Models of network dependencies . . . 120 6.2.1 Network model class hierarchy . . . . 120 6.2.2 Causal graph of network dependencies . . . . 121 6.2.3 Generic model vs network instance: self-modeling . . . . 123
The three-layer model described in the previous chapter is generic, in the sense that it defines the different types of network resources involved (for a given range of technologies), how they depend on each other and how they interact. The generic model defines the building blocks of a network, from a management perspective, but the actual network one has to manage contains many instances of these elements.
The actual network can be represented as a large collection of instances of the patterns described in the generic model, and these instances overlap on some common resources.
In this chapter, we use object oriented paradigm to represent IMS network resources and their relationships.
6.1 Different types of resources and their relationships
Our representation of IMS resources and dependencies is based on six important object classes: Equipment, Link,Function,Interface, Procedure, and Message such that each IMS resource inherits from (i.e. is a subclass of) one of the above classes; and four important relationships: is-connected-to, is-composed-of, is-supported-by, is-preceded-by.
113
114 Network model describing resource dependencies
6.1.1 Physical resources and their relationships
The physical layer containsphysical resources that belongs to two classes/types: equip-ment or link. We use Figure 6.1(a) and Figure 6.1(b) to describe these resources and illustrate the relationships between them.
IP
CPE DSLAM BRAS A-SBC Session
Controller
First Mile Aggregation Metro-core Other IP
networks Metro-access
Access Network
PSTN/ISDN
(a) The generic IMS physical architecture
CPE#1 DSLAM#1
(b) An instance of the generic IMS physical architecture
Figure 6.1: The generic IMS physical architecture and its instance
• Equipment. An instance of theEquipment class within the physical layer repre-sents a physical box. For example, CPE, displayed in Figure 6.1(a), is one of the subclasses inheriting fromEquipment. Other subclasses include DSLAM, BRAS, SBC, etc. In Figure 6.1(b), five instances CPE#1, CPE#2, CPE#3, CPE#4, CPE#5 of CPE have been displayed.
• Link. An instance of theLink class within the physical layer represents a network segment. For instance, First mile, displayed in Figure 6.1(a), is one of the sub-classes inheriting fromLink. Other subclasses include Aggregation, Metro-access, Metro-core, Access-network, Core-network, etc. In Figure 6.1(b), five instances:
first-mile#1, first-mile#2, first-mile#3, first-mile#4, first-mile#5 of this subclass have been displayed.
• is-connected-to. This relationship denotes the fact that an equipment (resp.
link) may connect to more than one link (resp. equipment). For example, DSLAM
Different types of resources and their relationships 115
is connected to first-mile in Figure 6.1(a), while in Figure 6.1(b) DSLAM#1 is connected first-mile#3.
• is-composed-of. This relationship denotes the fact that a link (or an equipment) is composed of other links and equipment. If a physical resourceXis composed of several physical resourcesX1, X2,· · ·, Xn, the set{X1, X2,· · ·, Xn}is called the set of descendants of X which is said to be the ancestor of each Xi, i= 1· · ·n.
For example, in Figure 6.1(a), Metro-access is composed of first-mile, DSLAM and Aggregation. As for Figure 6.1(b), it shows that Metro-access#1 is com-posed of five instances of mile (mile#1, mile#2, mile#3, first-mile#4, first-mile#5), two instances of DSLAM (DSLAM#1 and DSLAM#2) and one instance of Aggregation (Aggregation#1). This relationship enables to organize/analyse/view the physical IMS architecture on different levels of granu-larity. By a refinement operation we go from a coarse view of the architecture to a finest (more detailed) one.
• is-connected-to and is-composed-of. When (a) a physical resourceX is con-nected to another physical resourceY and (b)X has a non-empty set of descen-dantsX1, X2,· · ·, Xn, then at least one descendant of X is connected toY. For example, in Figure 6.1(a) where Metro-access is connected to BRAS and com-posed of first-mile, DSLAM, and Aggregation, the latter descendant is also con-nected to BRAS. Similarly, in Figure 6.1(b) Metro-access#1 and its descendant Aggregation#1 are connected to BRAS#1. The connectivity between equipment and links is preserved by the refinement and abstraction operations.
6.1.2 Functional resources and their relationships
The functional layer contains functional resources that are either functions or interfaces.
We use Figure 6.1(a) and Figure 6.1(b) to describe these resources and illustrate the relationships between them.
• Function. An instance of the Function class within the functional layer rep-resents a logical entity. For example, ARF displayed in Figure 6.2(a) is one of the subclasses inheriting fromFunction. Other subclasses include AMF, NACF, NASS, A-RACF, RACS, P-CSCF, Core-IMS, etc. In Figure 6.2(b), two instances ARF#1 and ARF#2 of ARF have been displayed.
• Interface. An instance of the Interface class within the functional layer repre-sents a reference point whereby functions can interact. For instance, e1 (between UE and ARF) displayed in Figure 6.2(a) is one of the subclasses inheriting Inter-face. Other subclasses include Gm (between UE and P-CSCF), e2 (between CLF and Core-IMS), Gq’ (between Core-IMS and RACS), etc. In Figure 6.2(b) two instances of e1 (between UE and ARF) have been displayed: e1#1 and e1#2.
• is-connected-to. This relationship denotes the fact that a function (interface) may connect to more than one interface (function). For example, in Figure 6.2(a),
116 Network model describing resource dependencies
(a) The generic IMS functional architecture
PSTN/ISDN
(b) An instance of the generic IMS functional architecture
Figure 6.2: The generic IMS functional architecture and its instance
Different types of resources and their relationships 117
UE is connected to e1 (between UE and ARF) while in Figure 6.2(b), UE#2 is connected to e1#2 (between UE#2 and ARF#2).
• is-composed-of. This relationship denotes the fact that a function (interface) is composed of other functions and interfaces. When a functional resourceXis com-posed of several functional resources X1, X2,· · ·, Xn. The set{X1, X2,· · · , Xn} is called the set ofdescendants ofAwhich is then said to be the ancestor of each Ai, i = 1· · ·n. For example, in Figure 6.2(a) NASS is composed of CNGCF, ARF, AMF, PDBF, UAAF, NACF, and CLF. As for Figure 6.2(b), it shows that NASS#2 is composed of CNGCF#2, ARF#2, AMF#2, PDBF#2, UAAF#2, NACF#2, and CLF#2. This relationship enables to organize/analyse/view the functional IMS architecture on different levels of granularity. By a refinement operation we go from a coarse view of the architecture to a finest (more detailed) one.
• is-connected-to and is-composed-of. When (i) a functional resource X is connected to another functional resource Y and (ii) X has a non-empty set of descendants X1, X2,· · · , Xn, then at least one descendant of X is connected to Y. For example, in Figure 6.2(a) where NASS is connected to A-RACF and is composed of CNGCF, ARF, AMF, PDBF, UAAF, NACF, and CLF. The latter descendant is connected to A-RACF. Similarly in Figure 6.2(b), NASS#1 and its descendant CLF#1 are connected to A-RACF#1. The connectivity between functions and interfaces is preserved by the refinement and abstraction operations.
6.1.3 Procedural resources and their dependencies
The procedural layer contains resources that are either procedures or messages. Below we present these resources and the relationships between them.
• Procedure. An instance of the Procedure class within the procedural layer rep-resents a procedure, a procedure-stage defined either by the standards or a more complex high-level service capability defined by the human expert. Examples of subclasses inheriting from Procedure are network attachment, IMS registration, IMS call origination, etc.
• Message. An instance of the Message class within the procedural layer repre-sents a request or a response sent from a function to another one via a refer-ence point. Examples of subclasses inheriting fromMessage are DHCP Discover, DHCP Offer, Register, Diameter UAR, Invite, 200 OK, etc. Sometimes, receiving a specific message or not receiving a message in time can be an explanation for an observed failure.
• is-preceded-by. This relationship denotes the fact that the execution of a proce-dure (message) requires to have, previously, successfully executed some prerequi-sites: other procedures or messages. For instance, the IMS registration procedure
118 Network model describing resource dependencies
is required before a terminal can execute the IMS call origination procedure. An-other example is the network attachment procedure, where CNG configuration is preceded by IP configuration. In the same manner, DHCP Offer is preceded by DHCP Discover. When a procedural resource Y is preceded by a procedural resourceX, we say thatX is apredecessor ofY that is then said to be asuccessor of X.
• is-composed-of. This relationship denotes the fact that a procedure is com-posed of other procedures and messages. Suppose that a functional resource X is composed of the following functional resources X1, X2,· · ·, Xn. The set {X1, X2,· · ·, Xn} is the set of descendants of X which is then said to be the ancestor of eachAi,i= 1· · ·n. For example, the Network attachment procedure as composed of three ordered procedures: IP configuration, CNG configuration and Location Management (TISPAN, 2010a) where IP configuration, displayed in Figure 6.3(a), is composed of procedure 1 and procedure 2. As illustrated in Figure 6.3, this relationship enables to organize/analyse/view a procedure on dif-ferent levels of granularity. By a refinement operation we go from a coarse view of the procedure to a finest (more detailed) one.
• is-preceded-by and is-composed-of. When (i) a procedural resource Y is preceded by another procedural resource X and (ii) Y has a non-empty set of descendants Y1, Y2,· · · , Yn, then each descendant of Y is preceded by X. For example, within IP configurationprocedure displayed in Figure 6.3(b), proce-dure 2 (composed of message (8) . . . messages (14)) is preceded by procedure 1 (composed of message (1) . . . message (7)). Each descendant of procedure 2 is preceded byprocedure 1.
6.1.4 Inter-layer relationships
The mapping between the generic physical and functional architectures of an IMS network describes how functions and interfaces are implemented into equipment and links. Figure 6.4 displays an example of mapping. Note that interfaces have not been displayed.
• is-supported-by.
– is-supported-by from the physical layer to the functional one. This rela-tionship denotes the fact that a functional resource (a function or an in-terface) is hosted into a physical resource (an equipment or a link). For example, in Figure 6.4, Core-IMS is supported by Core-network, NACF is supported by BRAS, e1 (between ARF and AMF) is supported by Aggre-gation.
– is-supported-by from the functional layer to the procedural one. This rela-tionship denotes the fact that the execution of a procedural resource (proce-dure or message) requires interactions of functions via interfaces connecting
Different types of resources and their relationships 119 5. DHCP Ack (IP address and
P-CSCF address)
Procedure 1
Procedure 2 Procedure 1A
Procedure 2A
(a) Coarse granularity of the IP configuration procedure
UE ARF
(b) Finest granularity of the IP configuration procedure
Figure 6.3: Two different levels of granularity for IP configuration procedure. The coarse granularity distinguishes a single resource denoted ‘NACF*’ that groups the ‘AMF’, the ‘NACF’, the ‘UAAF’, the communication interface between ‘AMF’ and ‘NACF’ ( ‘int AMF-NACF’) and the one between ‘NACF’
and ‘UAAF’ ( ‘int NACF-UAAF’). In the same manner, the chosen granularity distinguishes a single resource denoted ‘CLF*’ that groups the ‘CLF’, the ‘A-RACF’ and the communication interface ( ‘int CLF-A-RACF’) between these two functions.
120 Network model describing resource dependencies
IP
CPE DSLAM BRAS A-SBC Session
Controller
First Mile Aggregation Metro-core Other IP
networks
Figure 6.4: A mapping between the physical and the functional architecture (interfaces have not been displayed)
them. As an example, consider Figure 6.3(b) where the IP configuration pro-cedure is supported by NACF and message DHCP discover (2) is supported by e1 (between ARF and AMF).
• is-supported-by and is-composed-of.
– When (i) a functional (procedural) resource Y is supported by a physi-cal (functional) resource X and (ii) Y has a non-empty set of descendants Y1, Y2,· · ·, Yn, Then, at least one descendant of Y is supported by X. For example, in Figure 6.4 where Core-IMS is supported by A-SBC, one can see that P-CSCF is supported by A-SBC. Similarly, in Figure 6.3(b) where IP configuration procedure is supported by CLF, one can see that proce-dure 2 (started with DHCP request (8) and ended with DHCP ack (14)) is supported by CLF.
– When (i) a functional (procedural) resource Y is supported by a physi-cal (functional) resource X and (ii) X has a non-empty set of descendants X1, X2,· · ·, Xn, then Y is supported by at least one descendant of X. For instance, in Figure 6.4 where NASS is supported by Metro-network, one can see that NASS is supported by DSLAM. Similarly, the IP configuration pro-cedure displayed in Figure 6.3(a) and supported NACF*, is also supported by NACF (see Figure 6.3(b)).