Wireless Future - Telenor

More documents

Recommendations

Info

Figure 2 UML class diagrams for trail termination point 150 tmLayerNetworkDomain containerLND (1...1) layerNetwork DomainIsMadeOf element (1...N) tmNetworkTTP tmLayerNetworkDomain DEFINITION “This object class is derived from .” ATTRIBUTE -- none additional RELATIONSHIP layerNetworkDomainIsMadeOf 5) DEFINITION “The layerNetworkDomainIsMadeOf relationship class describes the relationship that exists between a layerNetworkDomain and the objects that compose it.” ROLE containerLND “Played by an instance of the information object type or subtype.” element “Played by an instance of the subtype of the information object type.” INVARIANT inv_containerLNDRoleCardinality “One and only one instance of the role containerLND must participate in the relationship.” inv_elementLNDRoleCardinality “One or more instances of the role element must participate in the relationship.” inv_signalIdentification “The containerLND and the element must contain the same signalIdentification information.” G.853.1: LayerNetworkDomain signalIdentification G.853.1: networkInformationTop resourceId 2.3 The Computational Viewpoint In the Computational Viewpoint, the dynamic system behaviour is described as interactions between computational objects constituting operational – as well as notification interfaces. The computational objects represent the finest granularity possible for computational objects in the mapping to objects in the Engineering Viewpoint. For each computational object, mappings are provided to the appropriate caller and provider roles in the Enterprise Viewpiont. The major part of the Computational Viewpoint deals with the specification of the operations belonging to each interface. The methodology used is commonly known as “Design by contract” [11]. Each operation request carries with it a number of input parameters and upon the successful execution, a number of output parameters are returned. Each parameter has a name, a type specifier and a value assigned. Every parameter is mapped to the corresponding Information Viewpoint element in the Parameter Matching clause. The invariant state of the system before and after the execution of each operation is specified by defining the state of the system components, i.e. the relationships and attributes supported. This is done in the form of a set of explicit pre- and post conditions. When violating any of them, specific exceptions are raised. For each exception, an explanatory text as well as a type specifier is provided. 5) This relationship defined in G.851.1 is included for the convenience of the reader. G.853.1: NetworkTTP signalIdentification pointDirectionality tmLayerNetworkDomain tmLayerNetworkTTP userLabel Telektronikk 1.2001
For every successful operation, a notification is generated to inform external recipients of the outcome of the event. The notification may contain additional information as required for the recipients to take advantage of the result. The operations are described in a communication protocol neutral fashion. Protocol specific constructs for the actual communication protocol implemented are added in the Engineering Viewpoint. The parameters are defined using the ASN.1 description language. An extract from the Computational Viewpoint specification for trail management describing the create networkTTP operation and the associated ASN.1 types, is shown below. The corresponding “Report networkTTP creation” notification is not shown. Create networkTTP OPERATION createNetworkTTP { INPUT_PARAMETERS layerND: LayerNetwork- DomainChoice; pointDir: PointDirectionality; suppliedUserIdentifier: UserIdentifier; -- zero length string or 0 implies none supplied. suppliedUserLabel: GraphicString; -- zero length implies none supplied. OUTPUT_PARAMETERS networkTTP: NetworkTTPChoice; RAISED_EXCEPTIONS userIdentifierNotUnique: UserIdentifier; failureToCreateNetworkTTP:NULL; failureToSetUserIdentifier: NULL; BEHAVIOUR SEMI_FORMAL PARAMETER_MATCHING layerND: ; suppliedUserIdentifier: ; pointDir: ; networkTTP: ; suppliedUserLabel: ; PRE_CONDITIONS inv_uniqueUserIdentifier “suppliedUserIdentifier shall not be equal to resourceId of any element in a Telektronikk 1.2001 relationship where layerND refers to containerLND.” POST_CONDITIONS inv_existingNetworkTTP “networkTTP and layerND must respectively refer to element and containerLND in a relationship.” inv_agreedUserIdentifier “resourceId of tmNetworkTTP referenced by networkTTP is equal to supplied- UserIdentifier, if it is supplied.” EXCEPTIONS IF PRE_CONDITION inv_uniqueUserIdentifier NOT_VERIFIED RAISE_EXCEPTION userIdentifierNotUnique; IF POST_CONDITION inv_existingNetwork- TTP NOT_VERIFIED RAISE_EXCEPTION failureToCreateNetworkTTP; IF POST_CONDITION inv_agreedUserIdentifier NOT_VERIFIED RAISE_EXCEPTION failureToSetUserIdentifier; } Supporting ASN.1 productions LayerNetworkDomainChoice ::= CHOICE { tmLayerNetworkDomainQueryIfce TmLayerNetworkDomainQueryIfce, userIdentifier UserIdentifier }; NetworkTTPChoice::= CHOICE { tmNetworkTTPQueryIfce TmNetworkTTPQueryIfce, userIdentifier UserIdentifier}; -- A query interface is an interface on the implemented object where properties such as the identifier of the object may be retrieved. 2.4 The Engineering Viewpoint The Engineering Viewpoint describes operations for specific interfaces based on a given communication protocol. Specifications exist already for CMIP [12, 13] and Corba IDL [14, 15, 16], and others will be provided. With CMIP, Managed Object classes representing network resources map to the network resources in the Enterprise Viewpoint. Actions map to operations in the Computational Viewpoint and name bindings and attributes map to the corresponding elements in the Information Viewpoint. The mapping scheme for Corba IDL is not finally decided yet. Another important feature is that of distribution. Within RM-ODP, there are mechanisms included to support a number of distribution types by implementing the corresponding transparencies. 151
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 150 and 151: 148 Each viewpoint constitutes a se
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?