-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathOMA_TEMPLATE_ArchDoc - Main.html
executable file
·482 lines (419 loc) · 21.8 KB
/
OMA_TEMPLATE_ArchDoc - Main.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
<!DOCTYPE html>
<html>
<head>
<title>OMA [ReleaseName] Architecture</title>
<meta charset="utf-8">
<script src="http://openmobilealliance.github.io/Tools/builds/respec-oma-common.js"
async class="remove">
</script>
<script class="remove">
var respecConfig = {
// for editor use
docType: "AD", // options are BASE, RD, AD, TS, SUP, ETS, ORG
subtitle: "OMA-AD-<short-name>_Vx_y",
shortName: "shortName",
otherLinks: [{
key: "Other Link",
data: [{
value: "Link Name",
href: "#location"
}]
}],
editors: [{
name: "Editor Name",
url: "http://example.com/",
company: "Editor Company",
companyURL: "http://example.org/",
mailto: "[email protected]",
note: "editor note"
}],
authors: [{
name: "Author Name",
url: "http://example.com/",
company: "Author Company",
companyURL: "http://example.org/",
mailto: "[email protected]",
note: "author note"
}],
// for staff only
specStatus: "DRAFT", // options are Draft, Candidate, Approved, Historic
publishDate: ""
};
</script>
</head>
<body>
<!-- table of content & table of figures -->
<section id="toc"></section>
<section id="tof"></section>
<section id="tot"></section>
<!-- start scope-->
<section>
<h2>Scope</h2>
<aside class="example">
<p>Briefly describe the scope of this document - how it presents the architecture of this particular enabler.
Include an explanation of how this architecture relates to Open Mobile Alliance activity.
If it adds clarity, also describe what is not in the scope of this architecture.</p>
<strong>DELETE THIS COMMENT</strong>
</aside>
</section>
<!-- end scope -->
<!-- start terminology and conventions -->
<section>
<h2>Terminology and Conventions</h2>
<!-- Start conventions -->
<section>
<h2>Conventions</h2>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [[RFC2119]]. All sections and appendixes, except "Scope"
and "Introduction", are normative, unless they are explicitly indicated to be informative.</p>
</section>
<!-- end conventions -->
<!-- Start Definitions -->
<section>
<h2>Definitions</h2>
<aside class="example">
<p>Add definitions in new rows of the following table as needed. The following examples show how dictionary references should be made as well as locally defined terms.
This table should be maintained in sorted alphabetic order based on the labels of the terms.</p>
<ul>Examples:
<li>Entity Use definition number 1 from [[OMADICT]]</li>
<li>Interactive Service Use definition from [[OMADICT]]</li>
<li>Local Term The definition description would be presented directly</li>
</ul>
<strong>TO BE DELETED</strong>
</aside>
<aside class="example">
<p>Add/Remove definition rows to this table as needed</p>
<strong>TO BE DELETED </strong>
</aside>
<p>Kindly consult [[OMADICT]] for more definitions used in this document.</p>
</section>
<!-- end Definitions -->
<!-- Start Abbreviations -->
<section>
<h2>Abbreviations</h2>
<aside class="example">
<p>Add abbreviations as needed to the following table. No special notation should be made regarding terms copied from the Dictionary.
This table should be maintained in alphabetic order.</p>
<strong>TO BE DELETED </strong>
</aside>
<p>OMA Open Mobile Alliance</p>
<aside class="example">
<p>Add/Remove definition rows to this table as needed</p>
<strong>TO BE DELETED</strong>
</aside>
<p>Kindly consult [[OMADICT]] for more abbreviations used in this document</p>
</section>
<!-- end abbreviations -->
</section>
<!-- end terminology and conventions -->
<!-- start introduction -->
<section>
<h2>Introduction</h2>
<aside class="example">
<p>Describe the high level architecture in greater detail than provided in section 1.
From a market perspective, this section should answer the following questions (in prose):</p>
<ul>
<li>What is the purpose of this architecture?</li>
<li>What problems does this architecture solve?</li>
</ul>
<strong>DELETE THIS COMMENT</strong>
</aside>
<!-- start version 1.0 -->
<section>
<h2>Version 1.0</h2>
<aside class="example">
<p>This section provides a high level, concise and informative description of the <strong>main functionality</strong> supported
in the initial enabler or reference release version described in this AD. The description should be brief,
target length should be a few paragraphs. When the enabler or reference release is finished, this description
should be aligned with the final functionality.</p>
<strong>DELETE THIS COMMENT</strong>
</aside>
</section>
<!-- end version 1.0-->
<!-- start version x.y -->
<section>
<h2>Version x.y</h2>
<aside class="example">
<p>This section provides a high level, concise and informative description of <strong>main functionality</strong> supported
in the initial enabler or reference release version described in this AD. The description should be brief,
target length should be a few paragraphs. When the enabler or reference release is finished, this description
should be aligned with the final functionality.</p>
<strong>DELETE THIS COMMENT</strong>
</aside>
<!-- start Version x.y.z -->
<section>
<h2>Version x.y.z</h2>
<aside class="example">
<p>This section should be included for each new service release covered with the AD.
It should describe at a high level the main changes made to the AD compared to the previous version.
The description should be brief, target length should be one paragraph.</p>
<strong>DELETE THIS COMMENT</strong>
</aside>
</section>
<!-- end Version x.y.z -->
</section>
<!-- end Version x.y -->
</section>
<!-- end introduction -->
<!-- start architectural model -->
<section>
<h2>Architectural Model</h2>
<aside class="example">
<p>This section defines the enabler’s architectural model. The model identifies: a) all internal functional
components of this enabler, and b) all of the communication relationships between the components of this enabler
and with other enablers and applications (including those specifications not defined by OMA).
This section SHOULD contain a diagram of the architecture. Diagrams in this section should contain logical entities only and not conflate
logical entities with physical entities. However, mobile terminals and networks may be shown because of their potential
relevance in the design of the architecture. Figure 1, Figure 2 (or a combination of them, if considered appropriate),
are illustrative examples of an architectural diagram and should be modified to reflect this architecture.
Working Groups SHOULD re-use functions specified by other enablers. Working Groups should consult other Architecture Documents and Specifications
to identify any of this architecture’s functionality (e.g. its systems, subsystems, interfaces and/or reference points, etc)
that is already specified.
This section MAY include an explanation and/or diagram to show how this architecture relates to the various views as defined in
“Inventory of Architectures and Services”. This diagram and explanation, however, are optional.</p>
<strong>DELETE THIS COMMENT.</strong>
</aside>
<!-- start dependencies -->
<section>
<h2>Dependencies</h2>
<aside class="example">
<p>This section MUST enumerate all of the dependencies this architecture has, in order to fulfil the approved enabler requirements
(both mandatory and optional). Dependencies in this context are other OMA enablers and non-OMA specifications (e.g. RFC 2616) this
enabler calls (i.e. re-uses). Each dependency MUST include a reference to the document(s) that specifies the depdency. All of these
references MUST also be included in Section 2.1.</p>
<p>The enumeration would be along the lines of a list with entries such as</p>
<ul>
<li>IMAP binary extension [[RFC3516]]</li>
</ul>
<p>where the reference (e.g. RFC3516 in this example) would link to the fully qualifed reference in section 2.1 table.
A dependency is actually to an interface and the intrinsic functions (required and re-used by this enabler) performed by the component
that exposes that interface.
Note: Dependencies should not be confused with deployment options.
If this architecture has no dependencies, then this section only needs to contain a statement as such.
If this architecture has dependencies on OMA Enablers, specific sub-sections shall describe those enablers and the interfaces used, as
well as the purpose for re-use in the context of this enabler.</p>
<strong>DELETE THIS COMMENT.</strong>
</aside>
<!-- start oma x enabler -->
<section>
<h2>OMA X Enabler</h2>
<aside class="example">
<p>This Enabler makes use of the following Interfaces from OMA X:</p>
<p>X-1 Interface is exposed by the X Enabler and SHALL be used by this enabler as detailed in [[X_AD]];</p>
<strong>DELETE THIS COMMENT.</strong>
</aside>
</section>
<!-- /end oma x enabler -->
<!-- start oma y enabler -->
<section>
<h2>OMA Y Enabler</h2>
<aside class="example">
<p>OMA Y EnablerThis Enabler makes use of the following Interfaces from OMA Y:</p>
<p>Y-1 Interface is exposed by the Y Enabler and SHALL be used by this Enabler as described in [[Y_AD]];</p>
<strong>DELETE THIS COMMENT.</strong>
</aside>
</section>
<!-- /end oma y enabler -->
</section>
<!-- end dependencies -->
<!-- start architectural diagram -->
<section>
<h2>Architectural Diagram</h2>
<aside class="example">
<p>This section contains the architectural diagram for the enabler. The examples in figures 1 and 2,
along with the legend, describe the drawing conventions to be followed. In some cases
(an example figure is not shown here) the resulting architecture diagram may contain combinations of
interfaces and reference points.</p>
<strong>DELETE THIS COMMENT.</strong>
</aside>
</section>
<!-- start architectural diagram -->
<figure id="fig1_example">
<img src="images/Architectural_Diagram.png"/>
<figcaption>Example of the Architectural Diagram using interfaces</figcaption>
</figure>
<br>
<figure id="fig2_example">
<img src="images/Architectural_Diagram_reference_points.png"/>
<figcaption>Example of the Architectural Diagram usingreference points</figcaption>
</figure>
<!-- start functional components and interfaces/reference points definition -->
<section>
<h2>Functional Components and Interfaces/reference points definition</h2>
<aside class="example">
<p>This section describes all of the architecture’s functional components and the specified interfaces and/or reference points.
As a general guidance, the Architecture Document SHOULD define interfaces, wherever possible.
Each of the components should be described in a separate subsection and MUST contain at least the following information:</p>
<ul>
<li>Name</li>
<li>Description</li>
<li>Responsibility (e.g. what does the component do/perform)</li>
</ul>
<p>Each component SHOULD have at least one interface or at least one reference point that can be used by some other functional component, enabler, application, etc</p>
<p>All of the interfaces and/or the reference points should be described in this section.</p>
<p>Interfaces and reference points MUST be described in a language-independent way.</p>
<p>Each interface description MUST include at least the following information:</p>
<ul>
<li>Name</li>
<li>Description</li>
<li>Entity that exposes the interface</li>
</ul>
<p>Each reference point description MUST include at least the following information:</p>
<ul>
<li>Name</li>
<li>Description of all the functions exposed between the two entities</li>
<li>The two entities that are linked by this reference point</li>
</ul>
Each reference point description SHOULD include the following information:
<ul>
<li>Name of each interface included in the reference point</li>
<li>Description of each interface included in the reference</li>
<li>Interface/reference point naming convention:</li>
</ul>
<p>The name of an interface/reference point consists of a minimal number of characters (e.g. no longer than the WID's registered name), followed by a dash, followed by
a running number (starting at “1” and counting upwards in steps of 1 for each new interface/reference point). Each work group decides about the character(s) for their
interfaces/reference point as long as there is no duplication with already existing names (work groups can consult ARC to confirm). Names should be chosen in an intuitive
way to allow easy recognition of the interface/reference point. Some examples are:</p>
<pre>
B-1 B stands for “Browsing”
POC-5 POC stands for “Push to Talk over Cellular”
MMS-7 MMS stands for “Multimedia Messaging”
</pre>
<p>Interface re-use convention: In case an interface from another enabler is re-used (e.g. exactly as is, as a profiled subset, or extended with additional Attribute Value Pairs)
the interface name is that of the other enabler. That is, the interface name does not change, since the interface does not fundamentally change. The interface structure and
placement of parameters and/or AVPs are already defined as part of the other enabler.</p>
<p>Reference points re-use convention:</p>
<p>In case a reference point from another enabler is re-used (i.e. all of its interfaces, and the two entities, as originally defined, linked through the reference point) then,
the reference point name is that of the other enabler. That is, the reference point name does not change, since the reference point does not fundamentally change.
The reference point structure and placement of parameters and/or AVPs are already defined as part of the other enabler.</p>
<p>Detailed recommendations on how to re-use reference points may be found in the <i>“Architecture Best Practices”</i> document.</p>
<p>Graphical representation convention:
Reference points are depicted as a line and interfaces are depicted as an arrow.</p>
<strong>DELETE THIS COMMENT</strong>
</aside>
</section>
<!-- end functional components and interfaces/reference points definition -->
<!-- start security considerations -->
<section>
<h2>Security Considerations</h2>
<aside class="example">
<p>Describe security functionalities based on security requirements defined in corresponding Requirement Document.
Security functionalities should address and consider at least the following features:<p>
<ul>
<li>Authentication</li>
<li>Authorization</li>
<li>Data integrity</li>
<li>Confidentiality</li>
<li>Non-repudiation</li>
</ul>
<strong>DELETE THIS COMMENT</strong>
</aside>
</section>
<!-- end security considerations -->
<!-- start charging considerations -->
<section>
<h2>Charging Considerations</h2>
<aside class="example">
<p>Describe charging functionalities based on charging requirements defined in corresponding Requirement Document.
The following text MAY be used to identify functional components that may report Chargeable Events. If used, “X” SHALL be replaced
by the name of the enabler being specified and “[OMA X RD]” SHALL be replaced by a reference to the Requirements Document for the enabler,
and “OMA X functional entity 1,2,..” SHALL be replaced by a list of functional components of the enabler that may report Chargeable Events.</p>
<strong>DELETE THIS COMMENT</strong>
</aside>
<p>
The underlying network or other suitable entity may need to support the receiving of charging data or charging events triggered from an external mechanism in order
to fulfil the charging requirements described in [OMA X RD]. One such mechanisms is triggering through the OMA Charging Enabler.
The OMA Charging Enabler [OMA-CHG-AD] coordinates charging data triggers and flow from OMA X enablers into an underlying charging infrastructure, supporting charging mechanisms,
e.g. Online, Offline, Price Points. Functional components that may optionally report Chargeable Events are:</p>
<ul>
<li>OMA X functional entity 1</li>
<li>OMA X functional entity 2</li>
<li>...</li>
</ul>
</p>
<aside class='example'>
<p>If the specification refers to common Charging functionality and does not involve specific Charging related specifications,
this section MAY end with the following text:</p>
<strong>DELETE THIS COMMENT</strong>
</aside>
<p>The interaction between these functional entities and the OMA Charging Enabler is described in [OMA-CHG-AD]. Description of how charging is performed is beyond the scope of the present specification.</p>
<aside class='example'>
<p>If the specification involves specific Charging related functionality, then this section MAY include following text for each functional entity listed above.
If used, “OMA X functional entity i” SHALL be replaced by one of the functional entities listed above, and “[TS X Charging]” SHALL be replaced by a reference to the Technical Specification
document where the charging functionality for this functional entity is defined. Please don’t forget to add this reference to section 2.2 above!</p>
<strong>DELETE THIS COMMENT</strong>
</aside>
<p>
The interaction between OMA X functional entity and the OMA Charging Enabler is described in [TS X Charging]. Description of how charging is performed is beyond the scope of the present specification.
</p>
<aside class='example'>
<p>These texts are guidelines only and this section MAY contain alternative or additional text to explain the charging considerations for this enabler, if any.
</p>
<strong>DELETE THIS COMMENT</strong>
</aside>
</section>
<!-- end charging considerations -->
</section>
<!-- end architectural model -->
</section>
<!-- start appendix b. flows(informative) -->
<section class="appendix">
<h2>Appendix B. Flows (informative)</h2>
<aside class='example'>
<p>The objective of this section is to describe the high-level logical flows between the architectural entities.
These flows should just serve for a better understanding of the architecture. Therefore it is recommended to add a minimum number of flows, which should be
very high-level.</p>
<strong>DELETE THIS COMMENT.</strong>
</aside>
</section>
<!-- end appendix b. flows(informative) -->
<!-- start additional information -->
<section>
<h2>Additional Information</h2>
<aside class='example'>
<p>If needed, add annex to provide additional information to support the document. In general, this information should be informative, as normative material should be
contained in the primary body of the document.
Note that the styles for the headers in the appendix (App1, App2, App3) are different than the main body. The use below is intended to validate the styles to be used.
Remove if not needed.</p>
<strong>DELETE THIS COMMENT.</strong>
</aside>
<!-- start app headers -->
<section>
<h2>App Headers</h2>
<p> Text goes here.</p>
<!-- start More Headers -->
<section>
<h2>More Headers</h2>
<p> More text goes here.</p>
</section>
<!-- end More Headers -->
</section>
<!-- end App Headers -->
</section>
<!-- end additional information -->
<br>
<section>
<table>
<caption>Example Table</caption>
<thead>
<tr>
<td> </td>
<td>Column1</td>
<td>Column2</td>
</tr>
</thead>
<tbody>
<tr>
<td>Row 1</td>
<td>Grid 1,1 data</td>
<td>Grid 2,1 data</td>
</tr>
<tr>
<td>Row 2</td>
<td>Grid 1,2 data</td>
<td>Grid 2,2 data</td>
</tr>
</tbody>
</table>
</section>
</body>
</html>