MTA- Media Terminal AdapterDECT- Digital Enhanced Cordless TelecommunicationsHAL- Hardware Abstraction LayerRDK-B- Reference Design Kit for Broadband DevicesOEM- Original Equipment ManufactureDSX- Digital Signal Cross-connectTN- Telephone NumberDHCP- Dynamic Host Configuration ProtocolDHCPv6- Dynamic Host Configuration Protocol for IPv6PIN- Personal Identification Number
The diagram below describes a high-level software architecture of the MTA(Media Terminal Adapter) HAL module stack.
MTA HAL is an abstraction layer implemented to abstract the underlying MTA hardware and interacts with the underlying voice vendor software through a standard set of APIs. An MTA can deliver Home Phone service in addition to High speed internet.
The below-mentioned APIs initialize the MTA HAL layers/code. The MTA client module should call the mentioned APIs initially during bootup/initialization.
mta_hal_InitDB()mta_hal_start_provisioning()
3rd party vendors will implement appropriately to meet operational requirements. This interface is expected to be blocked if the hardware is not ready.
The interface is not thread-safe.
Any module that is invoking the MTA HAL API should ensure calls are made in a thread-safe manner.
Vendors can create internal threads/events to meet their operation requirements. These should be responsible for synchronizing between the calls, and events and cleaning up on closure.
All APIs are expected to be called from multiple processes.
The client is responsible to allocate and deallocate memory for necessary APIs as specified in API Documentation. Different 3rd party vendors are allowed to allocate memory for internal operational requirements. In this case, 3rd party implementations should be responsible to de-allocate internally.
TODO: State a footprint requirement. Example: This should not exceed XXXX KB.
The HAL is not involved in any of the power management operations. Any power management state transitions MUST not affect the operation of the HAL.
There are no asynchronous notifications.
The APIs are expected to work synchronously and should be completed within a time commensurate with the complexity of the operation and by any relevant MTA specification. Any procedures that risk failure due to unresponsive connected devices should adhere to a timeout period. This timeout should be based on standard specifications or as stated in the corresponding API documentation, to maintain optimal lower interface operations.
TODO: Moving forward, we plan to specify the time limit within which tasks should be completed. This will involve fetching relevant information as needed, and we aim to clearly define this time-related expectation to avoid confusion in the future.
All HAL APIs are designed to return all errors synchronously as part of their return arguments. The responsibility to manage system errors such as memory shortages and errors must be returned so the caller can take appropriate action.
There is no requirement for HAL to persist any setting information. The caller is responsible for persisting any settings related to the MTA feature.
The following non-functional requirements should be supported by the component.
The MTA HAL component must record all errors and critical informative messages. This can be achieved by using either the printf or the syslog method. These tools are useful in identifying, and debugging the issues and understanding the functional flow of the system.
It is recommended that each HAL component follows the same logging process. If logging is required, vendors should log in to the mta_vendor_hal.log file, which can be found in the /var/tmp/ or /rdklogs/logs/ directories.
To ensure consistency with Linux standard logging, it is recommended that log levels be defined.
The component should not be contributing more to memory and CPU utilization while performing normal operations and commensurate with the operation required.
MTA HAL implementation should pass checks using any third-party tools like Coverity, Black Duck, Valgrind etc. without any issues to ensure quality.
There should not be any memory leaks/corruption introduced by HAL and underneath 3rd party software implementation.
MTA HAL implementation is expected to be released under the Apache License 2.0.
The source code should be able to be built under a Linux Yocto environment and should be delivered as a shared library named libhal_mta.so
Changes to the interface will be controlled by versioning, vendors will be expected to implement a fixed version of the interface, and based on SLA agreements move to later versions as demand requires.
Each API interface will be versioned using Semantic Versioning 2.0.0, and the vendor code will comply with a specific version of the interface.
None
All HAL function prototypes and datatype definitions are available in the mta_hal.h file.
- Components/Processes must include
mta_hal.hto make use of MTA HAL capabilities - Components/Processes must include linker dependency for
libhal_mta.so.
Covered as per "Description" sections in the API documentation.
sequenceDiagram
participant Client Module
participant MTA HAL
participant Vendor Software
Note over Client Module: Init once during bootup, Needed for Dependent APIs. <br> Ignore this if the caller doesn't have any Dependent APIs
Client Module->>MTA HAL: mta_hal_Initxxxxx()
MTA HAL->>Vendor Software:
Vendor Software->>MTA HAL:
MTA HAL->>Client Module: return
Client Module->>MTA HAL: mta_hal_start_provisioning()
MTA HAL->>Vendor Software:
Vendor Software->>MTA HAL:
MTA HAL->>Client Module: return
Client Module->>MTA HAL: mta_hal_Getxxxxx()
MTA HAL->>Vendor Software:
Vendor Software->>MTA HAL:
MTA HAL->>Client Module: return
Client Module->>MTA HAL: mta_hal_Setxxxxx()
MTA HAL->>Vendor Software:
Vendor Software->>MTA HAL:
MTA HAL->>Client Module: return