Design Updates Sample Clauses
The Design Updates clause establishes the process and conditions under which changes or modifications to a project's design can be made after initial approval. Typically, this clause outlines how updates are proposed, reviewed, and approved, and may specify who has authority to request or authorize such changes, as well as any associated costs or timelines. Its core practical function is to provide a clear framework for managing design changes, ensuring that all parties are aware of and agree to modifications, thereby minimizing disputes and maintaining project alignment.
Design Updates. (a) Each quarter during the Term, Wintegra and TI will discuss all subsystem improvements and modifications intended for the MP DSLAM Cooperative Reference Design and market conditions for the MP DSLAM Cooperative Reference Design, subject to the Parties’ respective confidentiality obligations to third parties.
(b) If either Party intends to disclose to a customer details with respect to such Party’s: (i) development of a component to be added to the MP DSLAM Cooperative Reference Design, or (ii) change to any component already included in the MP DSLAM Cooperative Reference Design; such Party shall disclose such details to the other Party in writing at least as soon as disclosing such details to the customer; provided, however, that the foregoing obligations shall not apply with respect to changes that do not have a material impact on the other Party’s Component Products (as implemented in the MP DSLAM Cooperative Reference Design) or the MP DSLAM Cooperative Reference Design as a whole.
(c) If Wintegra discovers any material discrepancy between the published specifications for its Component Product and actual performance of such Component Product in connection with the MP DSLAM Cooperative Reference Design, such that it may affect the interface between the TI Components and the Wintegra Components or the operation of the Wintegra Components, it will immediately alert TI as to the nature of this discrepancy and what steps, if any, will be taken to correct such discrepancy. If TI discovers any material discrepancy between the published specifications for its Component Product and actual performance of such Components Products such that if may affect the interface between the TI Components and the Wintegra Components or the operation of the Wintegra Components, TI will immediately alert Wintegra as to the nature of this discrepancy and what steps, if any, will be taken to correct such discrepancy.
Design Updates. Seller will have the right to change the manufacture and/or design of its Products if, in the judgment of Seller, such change does not alter the general function of the Products.
Design Updates. From Deliverable D4.1, the main design change is related to the deployment in the module. Previously, each client of a domain had to be configured as a client of the domain to which the secure connection was to be generated. Now, the inter-domain security module is designed to be deployed in the network gateways of each domain, so that they act as an intermediary between the end entities and the external domain. This reduces the complexity of configuring each network entity acting as a VPN client to the external domain. It also reduces the number of credentials required for the authentication and secure connection generation process. According to this design change, it has been necessary to add new interfaces (see Table 2-5) that are required to generate the connection between gateways. In this way, the connection can be generated directly by calling functions of the gateway acting as a client. In this sense, these interfaces should have strong authentication requirements, allowing only to trigger its functionality to trusted entities from external domains. These new interfaces are: Description This method adds a new client to the gateway acting as VPN server. The client is identified using its public key. Input Parameters Type Description client_public_key String Public key of the client to be added, in Curve25519 format. Output Parameters Type Description assigned_ip String Assigned IP to the new client. vpn_port Integer Port where the vpn server is running. server_public_key String Public key of the vpn server. Description This method adds a new client to the gateway acting as VPN server. The client is identified using its public key. Input Parameters Type Description ip_address_server String Public key of the client to be removed, in Curve25519 format. Output Parameters Type Description result Integer It indicates if the client public key has been removed successfully or not.
Design Updates. The VRM is designed to be a multi-container application, with the aim to provide the high level of flexibility required to immediately tackle any changes/updates in both resource composition and in the underlying 5G virtualised infrastructure. Due to this and in part to the fact that some features are still under definition or design, the final composition of such set of containers may vary during the following design and implementation phases, up to the final version of the prototype.
1. In this section we describe the updates to such set of features and also the initial software design of the components that were not ready to be reported in D4.1. Figure 4-1 shows to two main elements building the VRM and their relationship with the other components of the 5GZORRO platform. The Resource Manager contains the logic to manage the resource DB and interact with the Resource and Service Offer Catalogue (RSOC), which is the target of the resource definition translation process. The Resource Manager also offers an interface the MDA exploits for retrieving information used to reach the different components of the 5G Virtualisation platform, namely NFVO, VIM, Radio and Network Controller. Same interface is exploited by the e-Licensing modules to retrieve the coordinates to access the NFVO. Focusing into the Resource Manager module, it consists of several modules in charge to implement the functionality of resource storage (descriptors and, where required, packages), model translation, and 5G virtualisation infrastructure DB, as depicted in Figure 4-2. The Infrastructure GW provides the interface and the logic to access the underlying 5G Virtualised infrastructure, avoiding the need for components like MDA and e-Licensing modules to directly access the provider internal infrastructure. The Resource DB contains the resource definitions expressed in terms of descriptors and, when required, in terms of references to certain resource packages (e.g., the DB contains a VNF descriptor and a reference to the corresponding VNF package). The resource DB is managed by the Resource Manager Catalogue Handler (RMCH) that offers the interface and the logic to access to the resource information. The connection between the RM Catalogue Handler and the 5G Virtualised Infrastructure represents the capability of the Resource Manager to access the internal catalogues of the different elements to add (onboard), update, and remove resources. Finally, the Resource Definition Translator pro...
Design Updates. The main updates during this development period are mainly due implementation decisions, that have been focused in the internal communications between the centralized part of the e-Licensing Manager and their distributed components. Thus, the e-Licensing Manager consists of a microservice-based application offered in two main subsystems: • e-License Manager Core (eLMC) as a single point of presence inside the 5GZORRO Platform with the objective of centralizing TX and RX communications with the NSSO, the Marketplace, VNF Vendors and Operators. In D4.1 it was introduced as the eLicensing Context and Evaluation Manager, and now has evolved to the eLMC to centralize all the mentioned communications to the external entities, and brokering the requests to the different eLMAs, acting as the brain of the eLicensing Manager.
Design Updates. No design update has occurred with respect to the deliverable D4.
1. In fact, the main focus of the prototype for this intermediate 5GZORRO release has been on testing the SCONE framework capabilities.
Design Updates. The design and implementation of the NSSO has been evolved with a more mature definition and implementation of the interfaces between the different components, illustrated in Figure 4-5. In particular, the interface exposed to the ISSM has been defined based on the initial interface available from the software components and updated to allow passing IDs related to the 5G Offer transaction, which are passed to other modules to map resource allocations, and service instances to the smart contracts associated with the offer. The initial interfaces towards the Monitoring Data Aggregation (MDA) and the e-Licensing Manager modules have been established. Work is still ongoing to define the interface between the NSSO and the Network Service Mesh Manager (NSMM), to provision the connectivity between the different components of the end- to-end service, and between NSSOs in other domains to provision slices on top of 3rd party resources.
Design Updates. There are no significant changes in the ISSM-WFM design since deliverable D4.
1. In deliverable D2.3 [18], updated orchestration workflows have been presented which better capture the intended behaviours in scenarios such as cross-domain slice establishment, scale-out and optimization. Moreover, always in D2.3 updates have been provided about how ISSM-WFM integrates with the rest of the functional 5GZORRO architecture.
Design Updates. Currently there are no design updates as the software modules described in the previous version of the deliverable seem to work well. Well-defined and standardized software platforms are currently deployed and in use.
Design Updates. Novel considerations related to the integration of the Trust Management Framework with other 5GZORRO components (workflows) have emerged since the release of the related design in deliverable D4.1 (Jan. 2021). Therefore, a new internal workflow has been designed to better describe the interaction of the Trust Management Framework with other key modules and the triggered actions. As it can be observed in Figure 2-1, the Smart Resource and Service Discovery (SRSD) application module is the one in charge of launching the trust computation process for an initial list of offers pre-classified by the SRSD employing mechanisms such as intent-based priorities, imperative constraints and considerations provided by the consumer. Once the Trust Management Framework receives a set of offers to be evaluated, the framework will start the data collection process for each stakeholder associated with it. Hence, the following steps will be carried as many times as offers need to be assessed. The Trust Management Framework in each domain should possess a previously generated key pair (intra- domain keys), as well as a Decentralised Identifiers (DID). Each 5GZORRO Platform Participant of a particular domain must use the public key of its Trust Management Framework to share trust data into the Data Lake. Additionally, the Trust Management Framework should possess another global key pair (inter-domain keys) that could be used by other 5GZORRO Platform Participants (from other domains) in order to provide domain recommendations. These recommendations may subsequently be used by other participants who do not have previous information about a specific service or resource. Both key pairs (intra- and inter-domain) should be created by the Identity and Permission Manager before the 5GZORRO Platform Participant interacts with the Trust Management Framework. The impact of these changes is reflected in the workflow described in Figure 2-1. The Trust Management Framework will launch the startDataCollection method (see sec. 2.1 of deliverable
4.1 for details). Such capability will create new Data Lake pipeline that will retrieve trust information for each 5GZORRO Platform Participant using the two templates defined in sec. 5.1 of deliverable 4.1 (ref. step 5 in Figure 2-1). As an outcome of this step, the Data Lake platform will generate a new input and output ▇▇▇▇▇ topics which will be forwarded to the Trust Management Framework. It should be outlined that Data Lake ought to gather infor...