Wireless Future - Telenor

More documents

Recommendations

Info

148 Each viewpoint constitutes a self-contained specification of the system from a particular perspective. In addition, certain mappings between the viewpoints need to be established for the integrity of the overall system to be maintained. Because the target application is a model for management, only the system aspects subject to management, i.e. the management requirements, need to be represented in the model. The management requirements are expressed in terms of actions with associated policies (enforcements or restrictions). This is done in the Enterprise Viewpoint and implies that the requirements become an integrated part of the model itself. Another, equally important implication is that the Enterprise Viewpoint becomes a repository for management requirements, i.e. the management specification per se. 2.1 The Enterprise Viewpoint When compared with the original version of the RM-ODP framework, most of the changes pertain to the Enterprise Viewpoint. A finer granularity in the modelling approach is allowed, namely that of the network resource types defined in G.805. All the modelling constructs in the other viewpoints are provided with unique labels for backwards traceability to the functional requirements in the Enterprise Viewpoint. This is a fundamental mechanism for the support of conformance testing of implementations and also for requirement assessment during the specification phase. As previously mentioned, functional requirements are modelled as actions invoked by a caller role 3) and carried out by a provider role. In this context, an object is an entity that can be distinguished from other entities, has a separate existence and is described in terms of actions, policies and relationships with these other entities. Actions are enforced or restricted by action policies, that is – Permissions or Obligations respectively – to provide additional level of detail to the management specification. The caller has no knowledge of how the action is implemented. He only knows the action signature, i.e. the action name and the action policies. Actions naturally belonging together are grouped into functional units called Communities. Actions may also be combined in ordered series, Activities, to realize more comprehensive functionality. The provider may decide whether the full action sequence or an abstracted view in terms of a single high-level action is to be exposed to the caller. It is possible to create new communities by combining existing ones, by adding new functionality or deleting parts of the existing functionality. By taking advantage of existing actions when defining new communities, substantial reuse of specification and possibly implementation may be achieved. Policies may also be defined on the community- and the activity levels. For usage outside the context of its initial definition, the functionality provided by a community may be expressed through the Service Contract, essentially a listing of the functional contents. When making models on the Service Management level, the service contract may be used to define the technical part of the Service Level Agreement (SLA), the Service Level Specification (SLS). In addition to capturing the functional requirements the Enterprise Viewpoint also serves as the road map towards the other viewpoints. Actions in the Enterprise Viewpoint map to interface operations in the Computational Viewpoint. The client and provider roles map to computational objects. Enterprise actions are normally concerned with the manipulation (create, delete, associate, etc.) of G.805 network resources such as trails, access groups, link connections, etc. Network resources map to objects, attributes or relationships in the Information Viewpoint. When passing from the less formal architectural description of network resources in G.805 to a formal network model, additional element behaviour needs to be settled. Rec. G.852.2 [8] does that for the elements in G.805 and also provides definitions for some important elements currently missing in G.805. An extract from the Enterprise Viewpoint specification for trail management showing the community policy, role, action and service contract definitions for trail termination point creation is shown below. COMMUNITY trail management (tm) COMMUNITY_POLICY OBLIGATION signalId “Each resource in the community shall have the same signal identification”. 4) ROLE tm_caller “This role reflects the client of the actions defined within this community. One and only one caller role occurrence must exist in the community.” 3) In RM-ODP, a role is a fraction of the behaviour of an object, in this case an Enterprise object. 4) This is the same as requiring each resource to be part of the same layer network domain (LND). Telektronikk 1.2001
tm_provider “This role reflects the server of the actions defined within this community. One and only one provider role occurrence must exist in the community.” layer network domain “This role represents the layer network domain resource defined in Recommendation G.852.2. One and only one layer network domain role occurrence may exist in the community.” trail termination point “This role reflects the trail termination point resource defined in Recommendation G.852.2. Zero or more trail termination point role occurrences may exist in the community.” ACTION Create trail termination point “This action is used for the creation of a trail termination point. The caller has the ability to provide a unique user identifier to identify the trail termination point that has been created.” ACTION_POLICY OBLIGATION inputDirectionality “The caller shall specify the directionality of the trail termination point to be created.” PERMISSION inputUserId “The caller may provide a user identifier for the requested trail termination point.” OBLIGATION rejectUserIdNotUnique “If PERMISSION inputUserId is part of the contracted service and if the user identifier is not unique in the provider context, then the provider shall reject the action.” OBLIGATION provideUserId “If PERMISSION inputUserId is part of the contracted service, then the provider shall use the user identifier as the unique identifier when communicating with the caller.” OBLIGATION successReturnId “If PERMISSION inputUserId is not part of the contracted service, the provider shall, upon success of this action, return the unique identifier for the created trail termination point.” PERMISSION inputUserLabel “The caller may provide a user label for the requested trail termination point.” SERVICE CONTRACT tm_src COMMUNITY_POLICY OBLIGATION signalId; ROLE tm_caller, tm_provider, layer network domain, trail termination point ; ACTION Create trail termination point {OBLIGATION inputDirectionality, rejectUserIdNotUnique, provideUserId, successReturnId; PERMISSION inputUserId, inputUserLabel}; Telektronikk 1.2001 2.2 The Information Viewpoint The Information Viewpoint defines the static behaviour of the system in terms of information elements, i.e. objects, attributes and relationships. The behaviour of the information objects is made up of invariants, attributes and mandatory relationships. It may either be provided as structured English text or be described using the formal language Z [9]. Rec. G.853.1 [10] is a library constituting the information elements that may be directly defined on the basis of G.805 and G.852.2, that is, without taking functional requirements pertaining to any specific management area into account. When producing an Information Viewpoint specification for a specific functional area, the elements from the library are used as superclasses and specialisations are provided taking the additional requirements of the functional area in question into account. New elements may be added as well. Information elements are tagged back to the corresponding Enterprise Viewpoint elements, alternatively to elements in G.852.2. The Information Viewpoint is the ultimate source for the definition of the information elements within the system. This is reflected by the Parameter Matching clause in the Computational Viewpoint which maps the input- and output parameters to the corresponding information objects, attributes and relationships. The UML class diagrams, the information object-, attribute- and relationship definitions relevant to networkTTP creation are shown below. tmNetworkTTP DEFINITION “This object class is derived from .” ATTRIBUTE “ This attribute is imported from G.853.1 and is used as a user friendly label for the network- TTP.” RELATIONSHIP 149
Page 2 and 3:
Telektronikk Volume 97 No. 1 - 2001
Page 4 and 5:
Per Hjalmar Lehne (42) obtained his
Page 6 and 7:
Stein Svaet (41) is Senior Research
Page 8 and 9:
Pbit/day 6 150 125 100 75 50 25 0 F
Page 10 and 11:
8 Video communication as a utility
Page 12 and 13:
10 The idea of reconfigurable mobil
Page 14 and 15:
12 Switched lobe Dynamically phased
Page 16 and 17:
Figure 10 The All IP vision Figure
Page 18 and 19:
16 The IP world has some problems t
Page 20 and 21:
18 Abbreviations and acronyms less
Page 22 and 23:
Jorge Pereira (40) obtained his Eng
Page 24 and 25:
(Millions) Figure 1 Exponential gro
Page 26 and 27:
24 Defining Generation based upon D
Page 28 and 29:
Multi-mode Terminal by Software Rad
Page 30 and 31:
distribution layer possible return
Page 32 and 33:
30 A Co-Ordinated Approach to 4G As
Page 34 and 35:
Figure 2 Applications will grow fas
Page 36 and 37:
Figure 5 Evolution from multi-mode
Page 38 and 39:
Operator/Provider download librarie
Page 40 and 41:
Radio network subsystem - service c
Page 42 and 43:
Dr. Techn. Jørgen Bach Andersen (6
Page 44 and 45:
Figure 3 Two arrays with M and N el
Page 46 and 47:
Figure 5 Cumulative probability dis
Page 48 and 49:
Figure 8 As in Figure 5, but with F
Page 50 and 51:
48 Conclusion The challenge of prov
Page 52 and 53:
50 models are described simply by a
Page 54 and 55:
52 ping intervals or “quantizatio
Page 56 and 57:
Figure 3 ASE as a function of the a
Page 58 and 59:
56 7 Conclusion and Further Researc
Page 60 and 61:
Dave Wisely (39) graduated in 1982
Page 62 and 63:
Figure 2 Business case study Figure
Page 64 and 65:
Figure 6 BRAIN QoS architecture 62
Page 66 and 67:
64 4 BRAIN homepage. (2001, March 6
Page 68 and 69:
Figure 2 The Bluetooth protocol sta
Page 70 and 71:
Figure 5 A Bluetooth radio module i
Page 72 and 73:
70 • Instant postcard: A Bluetoot
Page 74 and 75:
72 work visions come true, it is ne
Page 76 and 77:
Table 1 Allocated HiperLAN bands (i
Page 78 and 79:
Figure 4 Basic MAC frame structure
Page 80 and 81:
78 Preamble BCH FCH ACHs Preamble S
Page 82 and 83:
throughput bit/s 80 3 2.5 2 1.5 1 0
Page 84 and 85:
82 5 References 1 CEPT. ERC Decisio
Page 86 and 87:
84 IETF Internet Engineering Task F
Page 88 and 89:
Figure 2-3 Mobile IPv6 architecture
Page 90 and 91:
88 domain, it attaches to a new lea
Page 92 and 93:
90 Domain GFA/MAP Figure 3-3 Archit
Page 94 and 95:
Geir Gylterud (35) is Research Scie
Page 96 and 97:
94 Framework Resource Resource Int
Page 98 and 99:
Figure 6 SCSs and network functiona
Page 100 and 101: Figure 9 The new business model. Fr
Page 102 and 103: 100 A strong consortium backs up th
Page 104 and 105: 102 Music Company Figure 3 Service
Page 106 and 107: Figure 4 OSA architecture service c
Page 108 and 109: Do van Thanh (43) obtained his MSc
Page 110 and 111: Figure 2 The first use case diagram
Page 112 and 113: 110 Box 1 - The Open Service Archit
Page 114 and 115: 112 X:User 1:Device 2:Device 3:Devi
Page 116 and 117: Figure 10 Initiating call from PSTN
Page 118 and 119: Figure 13 Splitting the incoming st
Page 120 and 121: Figure 17 A set of communication de
Page 122 and 123: 120 Box 3 continued Session Descrip
Page 124 and 125: Figure 21 A laptop and peripheral d
Page 126 and 127: 124 Box 4 - Bluetooth Bluetooth is
Page 128 and 129: 126 6 The ICEBERG project. (2001, M
Page 130 and 131: 128 new door towards the upcoming f
Page 132 and 133: ? Figure 1 The Mobile Service Platf
Page 134 and 135: Figure 2 Needs and Related Services
Page 136 and 137: 134 Telektronikk 1.2001
Page 138 and 139: 136 Telektronikk 1.2001
Page 140 and 141: Anne Lise Lillebø (52) is Adviser
Page 142 and 143: 140 with other SDOs (Standards Deve
Page 144 and 145: 142 Box 2 - ETNO Declaration We, th
Page 146 and 147: Arve Meisinset (52) is Senior Resea
Page 148 and 149: 146 In ITU-T we have seen needs to
Page 152 and 153: Figure 2 UML class diagrams for tra
Page 154 and 155: 152 The functionality describing th
Page 156 and 157: 154 9 Potter, B et al. An introduct
show all

Wireless Future - Telenor

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?