OMA_TEMPLATE_ArchDoc - Main.html

<h2>Scope</h2>
<section>
<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 -->
<p></p>
<!-- 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 -->
<p></p>
<!-- 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 -->
<p></p>
<!-- start architectural model -->
<section>
<h2>Architectural Model</h2>
<aside class="example">
<p>This section defines the enabler&rsquo;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&rsquo;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 &ldquo;Inventory of Architectures and Services&rdquo;. 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" alt="" /> <figcaption>Example of the Architectural Diagram using interfaces</figcaption></figure>
<br />
<figure id="fig2_example"><img src="images/Architectural_Diagram_reference_points.png" alt="" /> <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&rsquo;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 &ldquo;1&rdquo; 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 &ldquo;Browsing&rdquo;
               POC-5	POC stands for &ldquo;Push to Talk over Cellular&rdquo;
               MMS-7	MMS stands for &ldquo;Multimedia Messaging&rdquo;
			</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>&ldquo;Architecture Best Practices&rdquo;</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>
<p><strong>DELETE THIS COMMENT</strong></p>
</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, &ldquo;X&rdquo; SHALL be replaced by the name of the enabler being specified and &ldquo;[OMA X RD]&rdquo; SHALL be replaced by a reference to the Requirements Document for the enabler, and &ldquo;OMA X functional entity 1,2,..&rdquo; 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>
<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, &ldquo;OMA X functional entity i&rdquo; SHALL be replaced by one of the functional entities listed above, and &ldquo;[TS X Charging]&rdquo; SHALL be replaced by a reference to the Technical Specification document where the charging functionality for this functional entity is defined. Please don&rsquo;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 -->
<p></p>
<!-- 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) -->
<p></p>
<!-- 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 -->
<p>&nbsp;</p>
<section>
<table><caption>Example Table</caption>
<thead>
<tr>
<td>&nbsp;</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>