MTTR Sample Clauses

MTTR. The mean time to repair (MTTR) of a Base Radio Unit shall be a maximum of 30 minutes, excluding travel and access time. This repair time excludes repairs to any cabling to/from the BRU. [***] CONFIDENTIAL TREATMENT REQUESTED 72 39 GXx Xxxxx xx Multipoint Radio Subsystem Specification
Sample 1Sample 2
AutoNDA by SimpleDocs
MTTR. 1) SELLER shall use all commercially reasonable endeavours to maintain the On-Net POP Service Level on Mean Time to Restore (MTTR) within 8 hours 2) MTTR is calculated by averaging Time-to-Restore (TTR) by number of Network Outage in a month.
Sample 1
MTTR. The Mean Time to Repair (“MTTR”) goal measures the average Time to Repair (“TTR”) within a given month for CenturyLink to restore service after a qualified trouble ticket for a critical or high priority issue has been submitted. A qualified trouble ticket opened by Customer must provide adequate information for CenturyLink to begin the troubleshooting process. If the trouble ticket does not provide enough information for CenturyLink to begin troubleshooting, CenturyLink will attempt to contact the primary Customer contact to obtain the necessary information to complete the trouble ticket. TTR is measured from the time a qualified ticket is opened to the restoration of the affected seat(s). The MTTR goal is calculated by dividing the sum of all the TTR hours in a given month by the number of qualified tickets within the same month. MTTR SLA credits are limited to critical and high priority events. Targets for medium and low priorities and for Communication Points are intended to be informational only. Credit is applied to the MRC of the seats at the affected Customer locations. Any trouble ticket where the service issue is mitigated by use of a temporary solution will be closed once the temporary solution is implemented. A second, lower priority trouble ticket will be created to track further progress toward restoring the original configuration and other associated tasks. Any trouble ticket where the root cause is not found to be on the CenturyLink network or platforms will not count toward SLA calculations, commitments, or credits. MTTR (continued) Priority Description Examples Goal Remedy* Communication Points****
Sample 1Sample 2
MTTR. ‌ The MTTR (mean time to repair) refers to the time the Provider requires to replace defective hardware with functioning hardware. To measure the service level, the Provider documents the point in time when the downtime occurs and the point in time when the system is up and running again. When troubleshooting has been completed and any hardware problem has been repaired and the server has been restarted, the Provider informs the Customer and closes the service ticket. This action defines the end of the measured time period. The time the server requires to boot the operating system, reinstall any software or restore backup data is not included in the measurement of the service level.
Sample 1
MTTR. 5.3.1.1. MTTR is calculated per month, using the following formula: Cumulative Resolve Time of Priority 1 Trouble Tickets per Site, Circuit, or Service during the SCP
Sample 1
MTTR. Rogers offers you with a Mean Time to Repair (“MTTR”) performance objective that measures the duration of time that the Rogers Equipment that connects your Site to the Rogers Wireless Network is Out of Service, as set out in Table 3 below. Such Rogers Equipment encompasses all elements from, and including, the router-modem to the network antenna located at your Site. Customer Premise Equipment (CPE) is not considered as part of the network access. MTTR objectives are based on the location of your Site. MTTR objectives only apply to your Sites that are within one hundred and fifty (150) km (one way) of a Rogers’ Tech Support dispatch location. i) Mean Time to Repair (MTTR) is measured by calculating the average length of time it took to respond to and implement a repair for your particular access issue during a specific month. The MTTR is an objective only and Rogers will use commercially reasonable efforts to meet the objective. Rogers is not liable for any failure to meet the MTTR objective and you do not have a right to terminate as a result of Rogers’ failure to the meet the MTTR objective. MTTR metrics are measured solely against Out of Service conditions on the applicable Rogers Equipment. MTTR metrics are based solely on Out of Service statistics collected by the Rogers Trouble Reporting System (TRS), and exclude the following: a) an event of Force Majeure or other event beyond the reasonable control of Rogers; b) the Services are not available, or your end-user devices are unable to transmit data traffic due to the failure, malfunction or (including, without limitation, any applications or software thereon) or any other applications, systems or equipment not owned or controlled by Rogers including, without limitation, your Internet Service Provider connections; c) your individual end-user devices are unable to transmit and/or receive data due to reasons other than a Rogers Wireless Network outage affecting the Services; or d) the Rogers Wireless Network was unavailable due to planned, routine or emergency maintenance. e) The above service level objectives do not apply to the Services with unlimited usage plans.
Sample 1
MTTR. Rogers offers the Customer with a Mean Time to Repair (“MTTR”) performance objective that measures the duration of time that the Rogers Equipment that connects a Customer Site to the Rogers Wireless Network is Out of Service, as set out in Table 2 below. Such Rogers Equipment encompasses all elements from, and including, the router-modem to the network antenna located at the Customer Site. Customer Premise Equipment (CPE) is not considered as part of the network access. MTTR objectives are based on the location of the Customer’s Site. MTTR objectives only apply to Customer Sites that are within one hundred and fifty (150) km (one way) of a Rogers’ Tech Support dispatch location.
Sample 1
AutoNDA by SimpleDocs

Related to MTTR

  • Downtime There may be downtime during the Migration. The duration of the downtime will depend on the amount of data that Agency is migrating. Axon will work with Agency to minimize any downtime. Any VIEVU mobile application will need to be disabled upon Migration.

  • Traffic Measurement and Billing over Interconnection Trunks 6.1 For billing purposes, each Party shall pass Calling Party Number (CPN) information on at least ninety-five percent (95%) of calls carried over the Interconnection Trunks. 6.1.1 As used in this Section 6, “Traffic Rate” means the applicable Reciprocal Compensation Traffic rate, Measured Internet Traffic rate, intrastate Switched Exchange Access Service rate, interstate Switched Exchange Access Service rate, or intrastate/interstate Tandem Transit Traffic rate, as provided in the Pricing Attachment, an applicable Tariff, or, for Measured Internet Traffic, the FCC Internet Order. 6.1.2 If the originating Party passes CPN on ninety-five percent (95%) or more of its calls, the receiving Party shall xxxx the originating Party the Traffic Rate applicable to each relevant minute of traffic for which CPN is passed. For any remaining (up to 5%) calls without CPN information, the receiving Party shall xxxx the originating Party for such traffic at the Traffic Rate applicable to each relevant minute of traffic, in direct proportion to the minutes of use of calls passed with CPN information. 6.1.3 If the originating Party passes CPN on less than ninety-five percent (95%) of its calls and the originating Party chooses to combine Reciprocal Compensation Traffic and Toll Traffic on the same trunk group, the receiving Party shall xxxx the higher of its interstate Switched Exchange Access Service rates or its intrastate Switched Exchange Access Services rates for all traffic that is passed without CPN, unless the Parties agree that other rates should apply to such traffic. 6.2 At such time as a receiving Party has the capability, on an automated basis, to use such CPN to classify traffic delivered over Interconnection Trunks by the other Party by Traffic Rate type (e.g., Reciprocal Compensation Traffic/Measured Internet Traffic, intrastate Switched Exchange Access Service, interstate Switched Exchange Access Service, or intrastate/interstate Tandem Transit Traffic), such receiving Party shall xxxx the originating Party the Traffic Rate applicable to each relevant minute of traffic for which CPN is passed. If the receiving Party lacks the capability, on an automated basis, to use CPN information on an automated basis to classify traffic delivered by the other Party by Traffic Rate type, the originating Party will supply Traffic Factor 1 and Traffic Factor

  • Connectivity User is solely responsible for providing and maintaining all necessary electronic communications with Exchange, including, wiring, computer hardware, software, communication line access, and networking devices.

  • Start-Up and Synchronization Consistent with the mutually acceptable procedures of the Developer and Connecting Transmission Owner, the Developer is responsible for the proper synchronization of the Large Generating Facility to the New York State Transmission System in accordance with NYISO and Connecting Transmission Owner procedures and requirements.

  • Help Desk A help desk for Product support issues (the “Help Desk”) will be available to Customer. Unless specified in an Order, Customer should contact 000.000.0000 to receive a telephone number for the applicable supporting Solutions & Support Center. Customer will appoint one Product administrator and one backup administrator to serve as the primary point of contact regarding maintenance services.

  • One-Way Interconnection Trunks 2.3.1 Where the Parties use One-Way Interconnection Trunks for the delivery of traffic from Onvoy to Frontier, Onvoy, at Xxxxx’s own expense, shall: 2.3.1.1 provide its own facilities for delivery of the traffic to the technically feasible Point(s) of Interconnection on Frontier’s network in a LATA; and/or 2.3.1.2 obtain transport for delivery of the traffic to the technically feasible Point(s) of Interconnection on Frontier’s network in a LATA (a) from a third party, or, (b) if Frontier offers such transport pursuant to a Frontier access Tariff, from Frontier. 2.3.2 For each Tandem or End Office One-Way Interconnection Trunk group for delivery of traffic from Onvoy to Frontier with a utilization level of less than sixty percent (60%) for final trunk groups and eighty-five percent (85%) for high usage trunk groups, unless the Parties agree otherwise, Onvoy will promptly submit ASRs to disconnect a sufficient number of Interconnection Trunks to attain a utilization level of approximately sixty percent (60%) for all final trunk groups and eighty-five percent (85%) for all high usage trunk groups. In the event Onvoy fails to submit an ASR to disconnect One-Way Interconnection Trunks as required by this Section, Frontier may disconnect the excess Interconnection Trunks or bill (and Onvoy shall pay) for the excess Interconnection Trunks at the rates set forth in the Pricing Attachment. 2.3.3 Where the Parties use One-Way Interconnection Trunks for the delivery of traffic from Frontier to Onvoy, Frontier, at Frontier’s own expense, shall provide its own facilities for delivery of the traffic to the technically feasible Point(s) of Interconnection on Frontier’s network in a LATA.

  • Bypass Any of the steps in this procedure may be bypassed with mutual written consent of the parties involved at the time the bypass is sought.

  • Shift Rotation Routine shift rotation is not an approach to staffing endorsed by the Employer. Except for emergency situations where it may be necessary to provide safe patient care, shift rotation will not be utilized without mutual consent. If such an occasion should ever occur, volunteers will be sought first. If no one volunteers, the Employer will rotate shifts on an inverse seniority basis until the staff vacancies are filled.

  • Loop Provisioning Involving Integrated Digital Loop Carriers 2.6.1 Where Xxxx has requested an Unbundled Loop and BellSouth uses IDLC systems to provide the local service to the End User and BellSouth has a suitable alternate facility available, BellSouth will make such alternative facilities available to Xxxx. If a suitable alternative facility is not available, then to the extent it is technically feasible, BellSouth will implement one of the following alternative arrangements for Xxxx (e.g. hairpinning): 1. Roll the circuit(s) from the IDLC to any spare copper that exists to the customer premises. 2. Roll the circuit(s) from the IDLC to an existing DLC that is not integrated. 3. If capacity exists, provide "side-door" porting through the switch. 4. If capacity exists, provide "Digital Access Cross Connect System (DACS)- door" porting (if the IDLC routes through a DACS prior to integration into the switch). 2.6.2 Arrangements 3 and 4 above require the use of a designed circuit. Therefore, non- designed Loops such as the SL1 voice grade and UCL-ND may not be ordered in these cases. 2.6.3 If no alternate facility is available, and upon request from Xxxx, and if agreed to by both Parties, BellSouth may utilize its Special Construction (SC) process to determine the additional costs required to provision facilities. Xxxx will then have the option of paying the one-time SC rates to place the Loop.

  • Planned Outages Seller shall schedule Planned Outages for the Project in accordance with Good Industry Practices and with the prior written consent of Buyer, which consent may not be unreasonably withheld or conditioned. The Parties acknowledge that in all circumstances, Good Industry Practices shall dictate when Planned Outages should occur. Seller shall notify Buyer of its proposed Planned Outage schedule for the Project for the following calendar year by submitting a written Planned Outage schedule no later than October 1st of each year during the Delivery Term. The Planned Outage schedule is subject to Buyer’s approval, which approval may not be unreasonably withheld or conditioned. Buyer shall promptly respond with its approval or with reasonable modifications to the Planned Outage schedule and Seller shall use its best efforts in accordance with Good Industry Practices to accommodate Xxxxx’s requested modifications. Notwithstanding the submission of the Planned Outage schedule described above, Seller shall also submit a completed Outage Notification Form to Buyer no later than fourteen (14) days prior to each Planned Outage and all appropriate outage information or requests to the CAISO in accordance with the CAISO Tariff. Seller shall contact Buyer with any requested changes to the Planned Outage schedule if Seller believes the Project must be shut down to conduct maintenance that cannot be delayed until the next scheduled Planned Outage consistent with Good Industry Practices. Seller shall not change its Planned Outage schedule without Buyer’s approval, not to be unreasonably withheld or conditioned. Seller shall use its best efforts in accordance with Good Industry Practices not to schedule Planned Outages during the months of July, August, September and October. At Buyer’s request, Seller shall use commercially reasonable efforts to reschedule Planned Outage so that it may deliver Product during CAISO declared or threatened emergency periods. Seller shall not substitute Energy from any other source for the output of the Project during a Planned Outage.

Draft better contracts in just 5 minutes Get the weekly Law Insider newsletter packed with expert videos, webinars, ebooks, and more!