Примечание - ALTEL
реклама
АКЦИОНЕРНОЕ ОБЩЕСТВО «АЛТЕЛ» «УТВЕРЖДАЮ» Президент АО «АЛТЕЛ» Сауранбеков М.Т. «____» _______________ 2012 г. Приказ № 157 от «28» апреля 2012 г. ТЕНДЕРНАЯ ДОКУМЕНТАЦИЯ предоставляемая организатором тендера потенциальным поставщикам для подготовки тендерных заявок и участия в открытом тендере по закупу сетевого оборудования и услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения (4G) на базе технологии LTE «под ключ» 1 ТЕНДЕРНАЯ ДОКУМЕНТАЦИЯ по закупу сетевого оборудования и услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения (4G) на базе технологии LTE «под ключ» Тендер по закупу сетевого оборудования и услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения (4G) на базе технологии LTE «под ключ». Заказчик АО "АЛТЕЛ", 050057, город Алматы, ул.Жарокова 189, РНН 600600021605, IBAN (Р/С) KZ829261802100509000 (для платежей в KZT), IBAN (Р/С) KZ559261802100509001 (для платежей в USD) в АФ АО "Казкоммерцбанк", БИК KZKOKZKX , КБе 17, КНП 852, БИН 940140000206 1. Фонд – АО «Самрук-Қазына»; 2. Холдинг – совокупность Фонда и юридических лиц, пятьдесят и более процентов акций (долей участия) которых прямо или косвенно принадлежат Фонду на праве собственности или доверительного управления; косвенная принадлежность – принадлежность каждому последующему юридическому лицу пятидесяти и более процентов акций (долей участия) иного юридического лица на праве собственности или доверительного управления; 3. Сумма, выделенная для закупки: ЛОТ№1 4 125 000 000 (четыре миллиарда сто двадцать пять миллионов) тенге без учета НДС. 4. Базовые условия платежа: За оборудование: - 15% от общей стоимости оборудования в течение 30 календарных дней со дня заключения договора; - 85% от общей стоимости оборудования равными полугодовыми платежами в течение 3 лет со дня подписания Акта окончательной приемки сети. За услуги: - 15% от общей стоимости услуг в течение 30 календарных дней со дня заключения договора; - 35% от общей стоимости услуг в течение 30 календарных дней со дня получения Заказчиком официального уведомления от Поставщика о готовности всех объектов к монтажу. Допускаются частичные выплаты по факту получения Заказчиком официального уведомления от Поставщика о готовности группы объектов к монтажу (группа должна быть не менее 10 объектов), а к уведомлению должны быть приложены оригиналы документов, подтверждающих факт выполнения работ; - 50% от общей стоимости услуги в течение 30 календарных дней со дня подписания Акта окончательной приемки сети. Потенциальный Поставщик имеет право указать альтернативные условия оплаты в ценовом предложении по форме согласно Приложению 4 к Тендерной документации. Для тендерных предложений участников-резидентов Республики Казахстан: НДС оплачивается по мере возникновения налогового обязательства и представления счет-фактуры Поставщиком. Для тендерных предложений участников – нерезидентов Республики Казахстан в случае признания победителем по итогам тендера: Согласно Налоговому законодательству Республики Казахстан: - Предусмотрено обязательное удержание налога у источника выплат с дохода Поставщика от общей стоимости оказываемых Услуг по Договору; - При этом Поставщик вправе получить от Заказчика документ, подтверждающий удержание казахстанского налога. В случае если, страна происхождения Потенциального поставщика является участником международной Конвенции об избежании двойного 2 налогообложения, Поставщик вправе обратится в соответствующие государственные органы страны Заказчика с заявлением о возврате подоходного налога. Порядок налогообложения Заказчика и Поставщика регулируется действующим законодательством Республики Казахстан. - Банковские расходы, возникающие при исполнении Договора и других сопутствующих документов, на территории страны Заказчика оплачиваются Заказчиком, вне территории страны Заказчика - получателем платежа. 5. Размер обеспечения заявки на участие в тендере: 20 625 000 (двадцать миллионов шестьсот двадцать пять тысяч) тенге. 6. Заявки потенциальных поставщиков на участие в тендере принимаются по адресу: 050020, город Алматы, пр. Достык, 248Б, в срок до с 09-00 до 18-00 часов местного времени. Окончательный срок приема тендерных заявок до 11-00 часов местного времени «17» мая 2012 года. 7. Заседание тендерной комиссии по вскрытию конвертов с заявками потенциальных поставщиков на участие в тендере проводится по фактическому адресу: город Алматы, пр. Достык, 248Б, конференц-зал, «17» мая 2012 года, в 12-00 часов местного времени. 8. Регистрация потенциальных поставщиков (их уполномоченных представителей) и иных лиц, изъявивших желание участвовать при вскрытии конвертов, для участия в заседании тендерной комиссии по вскрытию конвертов с заявками потенциальных поставщиков производится по адресу: город Алматы, пр. Достык, 248Б, «17» мая 2012 года, до 12-00 часов местного времени. 9. Срок действия заявки на участие в тендере должен быть не менее 60 календарных дней c даты вскрытия конвертов с тендерными заявками. 1. Требования к потенциальным поставщикам 10. Для участия в тендере, потенциальный поставщик должен обладать: 1) Юридической правоспособностью; 2) являться Компанией-производителем, либо официальным представительством Компании-производителя закупаемого телекоммуникационного оборудования, либо его части; 3) иметь на территории Республики Казахстан представительство с квалифицированным техническим персоналом, готовым осуществлять первую линию поддержки по поставляемому оборудованию. 2. Оформление и представление заявки 11. Заявка потенциального поставщика на участие в тендере (далее – Заявка) является выражением согласия потенциального поставщика на поставку предмета Закупок в соответствии с требованиями и условиями, предусмотренными Тендерной документацией. Потенциальный поставщик несет ответственность за представление недостоверной информации. 12. Потенциальный поставщик должен представить Заявку к сроку, указанному в п.6 Тендерной документации. 13. Заявка должна быть прошита, страницы пронумерованы, последняя страница заверяется подписью и печатью потенциального поставщика. Техническое предложение (техническая спецификация) на участие в тендере (в прошитом виде, с пронумерованными страницами, последняя страница, заверенная подписью и печатью потенциального поставщика и оригинал документа, подтверждающего внесение обеспечения заявки на участие в тендере прикладываются отдельно. 14. Заявка запечатывается в конверт, на лицевой стороне которого должны быть указаны полное наименование и почтовый адрес потенциального поставщика, полное наименование и почтовый адрес Заказчика, а также текст следующего содержания: «ЗАЯВКА НА УЧАСТИЕ В ТЕНДЕРЕ ПО ЗАКУПУ СЕТЕВОГО ОБОРУДОВАНИЯ И УСЛУГ ПО ПЛАНИРОВАНИЮ, СТРОИТЕЛЬСТВУ, МОНТАЖУ И ПУСКО-НАЛАДКЕ, СДАЧЕ В ЭКСПЛУАТАЦИЮ СЕТИ МОБИЛЬНОЙ СВЯЗИ ЧЕТВЕРТОГО 3 ПОКОЛЕНИЯ (4G) НА БАЗЕ ТЕХНОЛОГИИ LTE «ПОД КЛЮЧ» и «НЕ ВСКРЫВАТЬ ДО: 12-00 ч. «17» мая 2012г. 15. Потенциальный поставщик должен представить один оригинал и одну копию Заявки, с указанием "ОРИГИНАЛ" и "КОПИЯ". В случае расхождений между ними, преимущество будет иметь оригинал. Дополнительно потенциальный поставщик должен предоставить не менее пяти электронных копий Заявки на CD-дисках, с полной информацией, содержащейся в бумажном виде запечатанных в конверте «КОПИЯ». 16. Заявка должна быть отпечатана или написана несмываемыми чернилами и подписана потенциальным поставщиком и скреплена печатью. 17. В Заявке не должно быть никаких вставок между строками, подтирок или приписок, за исключением тех случаев, когда потенциальному поставщику необходимо исправить грамматические или арифметические ошибки. 18. Все Заявки, полученные Заказчиком после истечения окончательного срока представления Заявок, не вскрываются и возвращаются представившим их потенциальным поставщикам по реквизитам, указанным на конвертах с Заявками либо лично уполномоченным представителям потенциальных поставщиков под расписку о получении. 19. Представленные потенциальными поставщиками или их уполномоченными представителями Заявки регистрируются в соответствующем журнале с указанием даты и времени приема Заявок. Не подлежат приему и регистрации конверты с Заявками с нарушением требований к оформлению конвертов с Заявками, предусмотренными в Тендерной документации. 20. Заявка составляется на русском языке. При этом Заявка может содержать документы, составленные на другом языке при условии, что к ним будет прилагаться точный перевод на язык Тендерной документации, и в этом случае преимущество будет иметь перевод. 3. Обеспечение Заявки 21. Потенциальный поставщик вносит обеспечение Заявки в размере, указанном в пункте 5 Тендерной документации, в качестве гарантии того, что он: 1) не отзовет либо не изменит свою Заявку после истечения окончательного срока предоставления Заявок; 2) в случае определения его победителем тендера заключит договор с Заказчиком в сроки, установленные протоколом об итогах тендера. 22. Потенциальный поставщик вправе выбрать один из следующих видов обеспечения Заявки: 1) гарантийный денежный взнос, который вносится на банковский счет Заказчика; 2) банковскую гарантию, по форме Приложения 5 к Тендерной документации. При этом срок действия банковской гарантии должен быть не менее срока действия тендерной заявки. 23. Все Заявки, не содержащие подтверждения внесения обеспечения Заявки, отклоняются тендерной комиссией, как не отвечающие требованиям Тендерной документации. В случае внесения обеспечения заявки на участие путем перечисления гарантийного денежного взноса на банковский счет Заказчика в подтверждающем документе должны быть указаны название тендера, сумма обеспечения, наименование Заказчика и потенциального поставщика. 24. Обеспечение Заявки не возвращается Заказчиком при наступлении одного из следующих случаев: 1) потенциальный поставщик отозвал либо изменил и (или) дополнил Заявку после истечения окончательного срока представления Заявок; 2) потенциальный поставщик, определенный победителем тендера в установленные сроки не подписал договор о закупках; 3) потенциальный поставщик, занявший по итогам сопоставления и оценки второе место в установленные сроки не подписал договор о закупках. 4 25. Заказчик возвращает потенциальному поставщику внесенное им обеспечение Заявки в течение 10 (десять) рабочих дней со дня наступления одного из следующих случаев: 1) отзыва данным потенциальным поставщиком своей Заявки до истечения окончательного срока представления Заявок; 2) подписания протокола об итогах тендера. Указанный случай не распространяется на участника тендера, определенного победителем, а также участника, занявшего второе место; 3) вступления в силу договора о закупках; 4) истечения срока действия Заявки потенциального поставщика. Обеспечение заявки на участие в тендере потенциальному поставщику, занявшему по итогам сопоставления и оценки второе место, возвращается в течение 10 (десяти) рабочих дней со дня заключения Договора закупок с победителем тендера. 4. Содержание Заявки 26. Заявка должна содержать: 1) заполненную и подписанную потенциальным поставщиком заявку по форме согласно приложениям 3 к Тендерной документации; 2) нотариально засвидетельствованную копию лицензии (в случае, если условиями тендера предполагается деятельность, которая подлежит обязательному лицензированию), либо копию лицензии, выданной в порядке, установленном законодательством об электронном документе и электронной цифровой подписи; 3) техническое предложение (техническая спецификация) потенциального поставщика; 4) оригинал документа, подтверждающего внесение обеспечения Заявки; 5) документы, подтверждающие применимость к Заявке критериев оценки, указанных в пункте 53 Тендерной документации; 6) ценовое предложение потенциального поставщика по форме согласно приложению 4 к Тендерной документации; 7) нотариально засвидетельствованную копию свидетельства о государственной регистрации (перерегистрации) юридического лица, для временного объединения юридических лиц (консорциум) - нотариально засвидетельствованную копию соглашения о консорциуме и нотариально засвидетельствованные копии свидетельств о государственной регистрации (перерегистрации) участников консорциума; 8) документ, содержащий сведения об учредителях: нотариально засвидетельствованную копию устава, утвержденного в установленном законодательством порядке (в случае участия консорциума представляется нотариально засвидетельствованная копия устава каждого юридического лица, входящего в консорциум), нотариально засвидетельствованную копию выписки из реестра держателей акций, выданную не более чем за 30 (тридцать) календарных дней до даты вскрытия конвертов; 9) оригинал или нотариально засвидетельствованную копию документа о назначении (избрании) первого руководителя потенциального поставщика (решение учредител(ей/я) или другого уполномоченного органа потенциального поставщика); 10) доверенность лицу (лицам), представляющему интересы потенциального поставщика, на право подписания Заявки и на участие в заседаниях тендерной комиссии, за исключением первого руководителя потенциального поставщика, имеющего право выступать от имени потенциального поставщика без доверенности, в соответствии с уставом потенциального поставщика. В таком случае потенциальный поставщик в обязательном порядке должен предоставить нотариально засвидетельствованную копию устава. 11) Иные документы, предусмотренные тендерной документацией в зависимости от предмета закупок. 27. Потенциальный поставщик, не являющийся резидентом Республики Казахстан, представляет те же документы, что и резиденты Республики Казахстан, в соответствии с пунктом 26 Тендерной документации, либо оригиналы или нотариально засвидетельствованные копии документов, содержащих аналогичные сведения о 5 потенциальном поставщике-нерезиденте Республики Казахстан с нотариально засвидетельствованным переводом на язык Тендерной документации. 28. В случае, если потенциальным поставщиком представляются документы, исходящие от компетентных органов и организаций иностранных государств, они принимаются при наличии консульской легализации, если иное не предусмотрено законодательством Республики Казахстан или международным договором, участниками которого являются Республика Казахстан и государство, от органов и организаций которого исходит представляемый документ. 29. Техническое предложение должно содержать: 1) документы, подтверждающие соответствие предлагаемого товара, работы, услуги Технической спецификации (Приложение 2 к Тендерной документации). 30. Ценовое предложение участника тендера, являющегося резидентом Республики Казахстан, должно быть выражено в тенге. Ценовое предложение участника тендера, не являющегося резидентом Республики Казахстан, может быть выражено в иной валюте. 31. Ценовое предложение должно содержать цену за единицу, а также общую цену товаров, работ и услуг, с включенными в нее расходами на их транспортировку и страхование, оплату таможенных пошлин, других налогов, сборов, а также иных расходов, предусмотренных условиями поставки товаров, выполнения работ, оказания услуг. Ценовое предложение потенциального поставщика может содержать скидку к общей цене товаров, работ, услуг, представленную на условиях Заказчика, определенных в тендерной документации, а также общую цену (скидку), предложенную потенциальным поставщиком с учетом альтернативных условий. 32. Предельные объемы работ и услуг, которые могут быть переданы потенциальным поставщиком субподрядчикам (соисполнителям) для выполнения работ, либо оказания услуг, являющихся предметом проводимых закупок или частью предмета закупок. Не допускается передача потенциальным поставщиком субподрядчикам (соисполнителям) на субподряд (соисполнение) в совокупности более двух третей объема работ (стоимости построения сети мобильной связи четвертого поколения (4G) на базе технологии LTE), услуг. 33. В случае привлечения потенциальным поставщиком субподрядчиков по выполнению работ (соисполнителей при оказании услуг), являющихся предметом проводимых закупок или частью предмета закупок, заявка на участие в открытом тендере должна содержать перечень субподрядчиков по выполнению работ (соисполнителей при оказании услуг), объем и виды передаваемых на субподряд (соисполнение) работ и услуг, который не должен превышать определенного в тендерной документации предельного объема работ и услуг. Заявка на участие в открытом тендере также должна содержать нотариально засвидетельствованные копии лицензий на выполняемые субподрядчиком работы (оказываемые соисполнителем услуги) в случае, если потенциальный поставщик привлекает субподрядчиков (соисполнителей) на тендер, которым предполагается деятельность, подлежащая обязательному лицензированию. 5. Изменение Заявок и их отзыв 34. Потенциальный поставщик может изменить и (или) дополнить свою Заявку до истечения окончательного срока представления Заявок. Внесение изменения и (или) дополнения должно быть подготовлено, запечатано и представлено так же, как и сама Заявка. 35. Уведомление об отзыве Заявки оформляется в виде произвольного заявления на имя Заказчика, подписанного потенциальным поставщиком и скрепленного печатью. 36. Внесение изменений и (или) дополнений в Заявку является действительными, если изменения получены Заказчиком до истечения окончательного срока представления Заявок. 6 37. Не допускается внесение изменений и (или) дополнений, равно как отзыв Заявки на участие в тендере, после истечения окончательного срока представления конверта с Заявкой. 38. Потенциальный поставщик несет все расходы, связанные с его участием в тендере. Заказчик, тендерная комиссия, экспертная комиссия, эксперт не несут обязательств по возмещению этих расходов независимо от итогов тендера. 6. Вскрытие конвертов с Заявками 39. Вскрытие конвертов с Заявками на участие в тендере производится тендерной комиссией в присутствии всех прибывших потенциальных поставщиков или их уполномоченных представителей в день, время и в месте, указанные в Тендерной документации. Вскрытию подлежат конверты с Заявками потенциальных поставщиков, представленные в сроки и в порядке, установленные Тендерной документацией. 40. Присутствующие на процедуре вскрытия конвертов с Заявками уполномоченные представители потенциальных поставщиков, должны предъявить секретарю тендерной комиссии документы, подтверждающие их полномочия, и зарегистрироваться в журнале регистрации прибывших потенциальных поставщиков в день, время и в месте, указанные в Тендерной документации. 41. Заявка на участие в тендере вскрывается также в случае, если на тендер (лот) представлена только 1 (одна) Заявка на участие в тендере (лоте). 42. На заседании тендерной комиссии: 1) председатель тендерной комиссии или лицо, определенное председателем из числа членов тендерной комиссии информирует присутствующих о: составе тендерной комиссии, секретаре тендерной комиссии; количестве потенциальных поставщиков, получивших копию тендерной документации; наличии либо отсутствии запросов потенциальных поставщиков, а также проведении встречи с потенциальными поставщиками по разъяснению положений тендерной документации; наличии либо отсутствии факта, а также причин внесения изменений и дополнений в тендерную документацию; потенциальных поставщиках, представивших в установленный срок Заявки на участие в тендере, зарегистрированные в журнале регистрации Заявок на участие в тендере; в хронологическом порядке оглашает сведения, внесенные в соответствующий журнал регистрации Заявок на участие в тендере, о каждом потенциальном поставщике, представившем Заявку на участие в тендере; оглашает иную информацию по данному тендеру; запрашивает уполномоченных представителей потенциальных поставщиков о наличии жалоб или возражений против действий (или бездействий) тендерной комиссии. 2) секретарь тендерной комиссии: вскрывает конверты с заявками на участие в открытом тендере и оглашает перечень документов, содержащихся в заявке и их краткое содержание, а также цены и скидки (при наличии), заявленные потенциальными поставщиками в ценовых предложениях; при желании уполномоченных представителей потенциальных поставщиков ознакамливает их с представленными ценовыми предложениями под роспись; оформляет соответствующий протокол вскрытия конвертов с Заявками на участие в тендере; информирует потенциальных поставщиков или их уполномоченных представителей о сроке, в течение которого они могут получить копию указанного протокола заседания тендерной комиссии. 43. Не допускается вмешательство потенциальных поставщиков или их уполномоченных представителей, присутствующих на заседании тендерной комиссии по вскрытию конвертов с Заявками, в деятельность тендерной комиссии. 7 44. Протокол вскрытия конвертов с Заявками на участие в тендере должен содержать следующие сведения: 1) день, время и место проведения заседания; 2) состав тендерной комиссии; 3) полное наименование, фактический адрес потенциальных поставщиков, получивших Тендерную документацию; 4) полное наименование, фактический адрес потенциальных поставщиков, предоставивших Заявки в установленные сроки, с указанием даты и времени предоставления Заявок; 5) информацию о содержании Заявок, в том числе документов, подтверждающих применимость к заявке критериев оценки, влияющих на условное понижение цены, указанных в пункте 53 Тендерной документации, ценах и скидках, заявленных потенциальными поставщиками в ценовых предложениях; 6) полное наименование, фактический адрес потенциальных поставщиков, которым возвращены Заявки ввиду их представления после окончательного срока представления Заявок; 7) жалобы или возражения против действий (или бездействия) тендерной комиссии, заявленные уполномоченными представителями потенциальных поставщиков в ходе заседания тендерной комиссии по вскрытию конвертов. 45. Протокол вскрытия конвертов с Заявками на участие в тендере подписывается и полистно визируется всеми присутствующими на заседании членами тендерной комиссии, ее председателем, его заместителем, а также секретарем тендерной комиссии в течение 1 (одного) рабочего дня, следующего за днем вскрытия конвертов с Заявками. 46. Копия указанного протокола предоставляется потенциальным поставщикам или их уполномоченным представителям, присутствовавшим на заседании тендерной комиссии по вскрытию конвертов с заявками на участие в тендере, не позднее 2 (двух) рабочих дней, следующих за днем указанного заседания тендерной комиссии, а отсутствующим по их письменному запросу в срок, не позднее 2 (двух) рабочих дней со дня получения запроса. 47. Не позднее 2 (двух) рабочих дней, следующих за днем указанного заседания тендерной комиссии, Заказчик опубликовывает на своем интернет-ресурсе и на интернетресурсе, определенном АО «Самрук-Қазына», текст подписанного протокола вскрытия конвертов с заявками на участие в тендере. 7. Порядок рассмотрения Заявок 48. Заявки рассматриваются тендерной комиссией на предмет соответствия Заявок требованиям Тендерной документации. Не отклоненные по основаниям, указанным в пункте 50 настоящей Тендерной документации, Заявки сопоставляются и оцениваются тендерной комиссией в целях выбора победителя тендера, предложившего наилучшие условия поставки закупаемых товаров, работ, услуг. Заявки рассматриваются тендерной комиссией в срок не более 10 (десяти) рабочих дней со дня вскрытия заявок на участие в тендере. При проведении закупок товаров, работ, услуг, имеющих сложные технические характеристики и спецификации, заявки рассматриваются тендерной комиссией с привлечением эксперта (экспертной комиссии) в срок не более 20 (двадцати) рабочих дней со дня вскрытия конвертов с заявками на участие в открытом тендере. 49. При рассмотрении Заявок тендерная комиссия вправе: 1) запросить у потенциальных поставщиков материалы и разъяснения, необходимые для рассмотрения, оценки и сопоставления Заявок (за исключением предложенной цены (скидок) и технической спецификации); 2) с целью уточнения сведений, содержащихся в Заявках, запросить необходимую информацию у соответствующих государственных органов, физических и юридических лиц. 8 При этом не допускаются запросы и иные действия тендерной комиссии, связанные с приведением Заявки на участие в тендере в соответствие с требованиями Тендерной документации, заключающиеся в дополнении Заявки недостающими документами, замене документов, приведении в соответствие ненадлежащим образом оформленных документов. 50. Тендерная комиссия отклоняет Заявку в случае: 1) признания заявки несоответствующей требованиям тендерной документации; 2) если потенциальный поставщик является аффилированным лицом другого потенциального поставщика, подавшего Заявку на участие в данном тендере (лоте); 3) ценовое предложение потенциального поставщика превышает сумму, выделенную для закупки; 4) ценовое предложение потенциального поставщика признано тендерной комиссией демпинговым. 5) потенциальный поставщик входит в Перечень ненадежных потенциальных поставщиков. 51. Ценовое предложение признаётся демпинговым в следующих случаях: 1) ценовое предложение на строительно-монтажные работы, по которым имеется проектно-сметная документация, утвержденная в установленном порядке, и проектноизыскательские работы, признаётся демпинговым, если оно более чем на 10 (десять) процентов ниже суммы, предусмотренной для закупки в плане закупок; 2) ценовое предложение на консультационные услуги признаётся демпинговым, если оно более чем на 70 (семьдесят) процентов ниже среднеарифметической цены всех представленных ценовых предложений, не превышающих сумму, предусмотренную для закупки в плане закупок; 3) ценовое предложение на работы, не указанные в подпункте 1) настоящего пункта, услуги, не указанные в подпункте 2) настоящего пункта, признаётся демпинговым, если оно более чем на 30 (тридцать) процентов ниже среднеарифметической цены всех представленных ценовых предложений, не превышающих сумму, предусмотренную для закупки в плане закупок. Положения настоящего пункта применяются к общей цене, предложенной потенциальным поставщиком с учетом скидки, представленной на условиях Заказчика, определенных в тендерной документации. Положения настоящего пункта не применяются к ценовому предложению потенциального поставщика, являющегося отечественным предпринимателем, имеющего опыт работы на отечественном рынке закупаемых работ или услуг не менее пяти лет. 52. Не отклоненные заявки сопоставляются и оцениваются тендерной комиссией согласно критериям, содержащимся в тендерной документации. Победитель открытого тендера определяется на основе наименьшей условной цены, рассчитываемой с учётом применения критериев, содержащихся в тендерной документации. Потенциальный поставщик, занявший по итогам сопоставления и оценки второе место, определяется на основе цены, следующей после наименьшей условной цены, рассчитываемой с учётом применения критериев, содержащихся в тендерной документации. При равенстве условных цен тендерных ценовых предложений победителем (или потенциальным поставщиком, занявшим по итогам сопоставления и оценки второе место) признается отечественный товаропроизводитель закупаемого товара. При равенстве условных цен тендерных ценовых предложений отечественных товаропроизводителей победителем (или потенциальным поставщиком, занявшим по итогам сопоставления и оценки второе место) признается отечественный товаропроизводитель, имеющий больший опыт работы производства закупаемых товаров. При равенстве условных цен тендерных ценовых предложений, в случае отсутствия отечественного товаропроизводителя, победителем (или потенциальным поставщиком, занявшим по итогам сопоставления и оценки второе место) признается потенциальный поставщик, имеющий больший опыт работы на рынке закупаемых товаров, являющихся предметом 9 открытого тендера. При равенстве условных цен тендерных ценовых предложений и равном опыте работы на рынке закупаемых товаров (или в случае невозможности определения опыта работы на основании представленных потенциальными поставщиками документов) победителем (или потенциальным поставщиком, занявшим по итогам сопоставления и оценки второе место) признается потенциальный поставщик, ранее предоставивший заявку на участие в тендере. В случае осуществления закупок работ, услуг при равенстве условных цен тендерных ценовых предложений победителем (или потенциальным поставщиком, занявшим по итогам сопоставления и оценки второе место) признается отечественный потенциальный поставщик закупаемых работ, услуг. При равенстве условных цен тендерных ценовых предложений отечественных поставщиков работ, услуг победителем (или потенциальным поставщиком, занявшим по итогам сопоставления и оценки второе место) признается отечественный поставщик работ, услуг, имеющий больший опыт работы на рынке закупаемых работ, услуг, являющихся предметом открытого тендера. При равенстве условных цен тендерных ценовых предложений, в случае отсутствия отечественного поставщика работ, услуг победителем (или потенциальным поставщиком, занявшим по итогам сопоставления и оценки второе место) признается потенциальный поставщик, имеющий больший опыт работы на рынке закупаемых работ, услуг, являющихся предметом открытого тендера. При равенстве условных цен тендерных ценовых предложений и равном опыте работы на рынке закупаемых работ или услуг (или в случае невозможности определения опыта работы на основании представленных потенциальными поставщиками документов) победителем (или потенциальным поставщиком, занявшим по итогам сопоставления и оценки второе место) признается потенциальный поставщик, ранее предоставивший заявку на участие в тендере. 53. Не отклоненные Заявки сопоставляются и оцениваются тендерной комиссией согласно критериям, содержащимся в настоящей Тендерной документации. Победитель тендера определяется на основе минимальной условной цены, рассчитанной с учетом применения следующих обязательных критериев: № 1 2 3 4 Критерий Потенциальный поставщик является отечественным товаропроизводителем закупаемого товара и состоит в соответствующем Реестре Холдинга Потенциальный поставщик является добросовестным поставщиком в соответствии с Перечнем добросовестных поставщиков Холдинга Потенциальный поставщик является организацией инвалидов, производящей закупаемый товар и состоит в соответствующем реестре Холдинга Наличие у потенциального поставщика опыта работы на рынке закупаемых товаров, работ, услуг, в течение последних 10 лет подтвержденного соответствующими оригиналами или нотариально засвидетельствованными копиями накладных и/или актов приема – передачи поставленных товаров, выполненных работ, оказанных Условное понижение/увеличение цены - 10% - 1% -5% - 1,5% за 3 года опыта работы и -0,5% за каждый последующий 1 год работы, но не более 5% 10 услуг; Наличие у потенциального поставщика сертифицированной системы (сертифицированных систем) менеджмента в соответствии с требованиями государственных стандартов соответствующей предмету проводимых закупок Казахстанское содержание в товаре потенциального поставщика, являющегося предметом проводимых закупок, которое определяется на основании сертификата происхождения товара (формы CT KZ) или заявления-декларации, выданного соответствующим уполномоченным органом при выпуске единичного, нестандартного, несерийного товара или товара, выпускаемого под заказ; - 1% 7 Гарантийное обязательство потенциального поставщика по доле казахстанского содержания в работах или услугах, подписанное первым руководителем потенциального поставщика либо лицом им уполномоченным, с указанием процентного значения казахстанского содержания в предлагаемых работах или услугах. - 0,1% за каждый 1% казахстанского содержания 8 Наличие у потенциального поставщика сертифицированной системы экологического менеджмента, в соответствии с требованиями государственных и международных стандартов -1% 9 Наличие у потенциального поставщика сертифицированной системы менеджмента охраны труда и производственной безопасности в соответствии с требованиями государственных и международных стандартов -1% 5 6 - 0,1% за каждый 1% казахстанского содержания 54. Под отечественным товаропроизводителем понимаются потенциальные поставщики юридические лица, являющиеся резидентами Республики Казахстан и производящие: товары, полностью произведенные в Республике Казахстан, перечисленные в пункте 5 Правил по определению страны происхождения товара, составлению и выдаче акта экспертизы о происхождении товара и оформлению, удостоверению и выдаче сертификата о происхождении товара, утвержденных постановлением Правительства Республики Казахстан от 22 октября 2009 года № 1647; товары, подвергнутые достаточной переработке в Республике Казахстан в соответствии с критериями достаточной переработки, установленными пунктом 7 Правил по определению страны происхождения товара, составлению и выдаче акта экспертизы о происхождении товара и оформлению, удостоверению и выдаче сертификата о 11 происхождении товара, утвержденных постановлением Правительства Республики Казахстан от 22 октября 2009 года № 1647; Под отечественными поставщиками работ, услуг понимаются юридические лица, являющиеся резидентами Республики Казахстан, использующие не менее девяноста пяти процентов местных трудовых ресурсов Республики Казахстан по выполнению работ, оказанию услуг; Под казахстанским содержанием понимается - процентное содержание стоимости оплаты труда граждан Республики Казахстан, задействованных в исполнении договора о закупках от общего фонда оплаты труда по данному договору и (или) стоимости доли (долей) казахстанского происхождения, установленной в товаре (товарах) в соответствии с критериями достаточной переработки или полного производства резидентами Республики Казахстан от общей стоимости товара (товаров) по договору о закупках; 55. Для определения казахстанского содержания в товаре потенциальный поставщик должен предоставить сертификат происхождения товара (формы CT KZ) или заявление – декларацию, выданное соответствующим уполномоченным органом при выпуске единичного, нестандартного, несерийного товара или товара, выпускаемого под заказ. 56. Победитель определяется путём выбора Заявки с наименьшей условной ценой, которая рассчитывается по формуле: Условная цена = Ценовое предложение Х (1 – совокупное снижение цены в %/100). В случае осуществления закупок товаров при равенстве условных цен тендерных ценовых предложений победителем признается отечественный товаропроизводитель, при равенстве условных цен отечественных товаропроизводителей победителем признается отечественный товаропроизводитель, имеющий больший опыт работы на рынке закупаемых товаров. В случае осуществления закупок работ, услуг при равенстве условных цен тендерных ценовых предложений победителем признается потенциальный поставщик, имеющий больший опыт работы на рынке закупаемых работ, услуг, являющихся предметом тендера. В случае непредставления потенциальным поставщиком документов, подтверждающих применимость к заявке критериев оценки, тендерная комиссия не применяет к такому потенциальному поставщику условную скидку, при этом непредставление таких документов, не является основанием для отклонения заявки на участие в тендере. 57. Если ценовые предложения участников тендера выражены в различных валютах, то для их оценки и сопоставления они переводятся в валюту Республики Казахстан, тенге, по официальному курсу национальной валюты Республики Казахстан к иностранным валютам, установленному Национальным Банком Республики Казахстан, на день вскрытия конвертов с Заявками. 8. Подведение итогов тендера 58. В срок, указанный в пункте 48 Тендерной документации, тендерная комиссия подводит итоги тендера, которые оформляются протоколом. Протокол об итогах тендера подписывается и полистно визируется всеми членами тендерной комиссии и её секретарём. В протоколе об итогах тендера должна содержаться информация: - о месте и времени подведения итогов; - о поступивших Заявках потенциальных поставщиков на участие в тендере; - о сумме выделенной для закупки, предусмотренной годовым планом закупок; - об отклоненных Заявках, основаниях отклонения; - о потенциальных поставщиках, признанных соответствующими требованиям тендерной документации; - о результатах применения критериев оценки; - об итогах тендера; - о сумме и сроках заключения договора о закупках в случае, если тендер состоялся; - о потенциальном поставщике, занявшем второе место; - сведения о направлении в соответствии с пунктом 49 настоящей тендерной 12 документации запросов потенциальным поставщикам, соответствующим государственным органам, физическим и юридическим лицам; - иная информация по усмотрению тендерной комиссии. 59. Тендер признаётся тендерной комиссией несостоявшимся в случае: 1) представления менее 2 (двух) Заявок на участие в тендере; 2) если после отклонения тендерной комиссией по основаниям, предусмотренным пунктом 50 настоящей Тендерной документацией, осталось менее двух заявок на участие в тендере потенциальных поставщиков; 3) уклонения победителя тендера и потенциального поставщика, занявшего второе место, от заключения договора. 60. Заказчик не позднее 3 (трех) рабочих дней со дня подписания протокола об итогах тендера: 1) направляет победителю уведомление; 2) размещает протокол об итогах открытого тендера на интернет-ресурсе Заказчика и на интернет-ресурсе, определенном АО «Самрук-Қазына»; 3) публикует информацию об итогах открытого тендера в периодическом печатном издании, распространяемом на всей территории Республики Казахстан, с периодичностью издания не менее 3 (трех) раз в неделю. 61. Заказчик не позднее 3 (трех) рабочих дней со дня получения письменного запроса потенциального поставщика, сведения о котором внесены в журнал регистрации заявок, должен представить ему на безвозмездной основе копию протокола об итогах тендера. 62. Заказчик вправе на любом этапе закупок отказаться от осуществления закупок в случаях сокращения расходов на приобретение товаров, работ, услуг, предусмотренных в годовом плане закупок, обоснованного уменьшения потребности или обоснованной нецелесообразности приобретения товаров, работ, услуг, закупаемых на данном тендере. В этом случае Заказчик обязан: 1) в течение 3 (трех) рабочих дней со дня принятия решения об отказе от осуществления закупок известить об этом лиц, участвующих в проводимых закупках и опубликовать соответствующее объявление на интернет-ресурсе Заказчика и на интернет-ресурсе, определенном АО «Самрук-Қазына»; 2) в течение 5 (пяти) рабочих дней со дня принятия решения об отказе от осуществления закупок возвратить внесенные обеспечения заявок. 63. В случае обнаружения нарушений в проводимом/проведенном открытом тендере тендерная комиссия до момента заключения договора обязана отменить итоги тендера. Заказчик в течение 2 (двух) рабочих дней со дня принятия решения об отмене тендера или его итогов обязан известить об этом лиц, участвовавших в проводимых закупках и опубликовать соответствующее объявление на интернет-ресурсе Заказчика и на интернетресурсе, определенном Фондом. 9. Заключение договора о закупках по итогам тендера 64. Договор о закупках заключается в соответствии с содержащимся в Тендерной документации проектом договора (приложение 8 настоящей Тендерной документации). 65. Договор о закупках, заключается в сроки, указанные в протоколе об итогах тендера, но не более 20 (двадцати) календарных дней с даты подписания протокола об итогах тендера. В случае если договор заключается с нерезидентами Республики Казахстан данный срок может быть продлен до 20 (двадцати) рабочих дней. Допускается доработка проекта договора, прилагаемого к Тендерной документации, с учётом предложений победителя тендера в части условий, предусмотренных пунктом 66 Тендерной документации. При этом вносимые изменения в проект договора о закупках не должны затрагивать условия договора, касающиеся наименования товара, работы, услуги, цены и другие условия, явившиеся основой для выбора поставщика. 66. Внесение изменений в проект договора о закупках допускается по взаимному согласию сторон: 13 1) в части уменьшения суммы проекта договора при условии неизменности качества и других условий, явившихся основой для выбора поставщика; 2) в случае принятия Заказчиком альтернативных условий потенциального поставщика; 3) в случае отказа либо изменения условий выплаты аванса (предоплаты). 67. Внесение изменения в заключенный договор о закупках при условии неизменности качества и других условий, явившихся основой для выбора поставщика, допускается: 1) по взаимному согласию сторон в части уменьшения цены на товары, работы, услуги и соответственно суммы договора, если в процессе исполнения договора о закупках цены на аналогичные закупаемые товары, работы, услуги изменились в сторону уменьшения; 2) в части уменьшения или увеличения суммы договора, также в части соответствующего изменения сроков исполнения договора, если в проектно-сметную документацию, прошедшую государственную экспертизу, внесены изменения и принято решение о дополнительном выделении денег на сумму такого изменения, принятое в установленном порядке; 3) в части уменьшения либо увеличения суммы договора, связанной с уменьшением либо увеличением потребности в объеме приобретаемых товаров, работ, за исключением работ, указанных в подпункте 2) настоящего пункта, услуг, также в части соответствующего изменения сроков исполнения договора, при условии неизменности цены за единицу товара, работы, услуги, указанных в заключенном договоре о закупках данных товаров, работ, услуг. Такое изменение заключенного договора о закупках товаров, работ, услуг допускается в пределах сумм, предусмотренных в годовом плане закупок для приобретения данных товаров, работ, услуг; 4) в случае, если поставщик в процессе исполнения заключенного с ним договора о закупках товара предложил при условии неизменности цены за единицу товара более лучшие качественные и (или) технические характеристики либо сроки и (или) условия поставки товара, являющегося предметом заключенного с ним договора о закупках товара; 5) в части уменьшения или увеличения суммы договора на выполнение работ со сроком завершения в следующем (последующих) году (годах), вызванных изменением законодательства в налоговой, таможенной и других сферах либо стоимости труда и материальных ресурсов, а также в части соответствующего изменения сроков исполнения договора в случае изменения финансирования по годам, при условии внесения соответствующих изменений в проектно-сметную документацию, прошедшую государственную экспертизу. 6) в части уменьшения или увеличения суммы долгосрочного договора о закупках на поставку товаров, оказание услуг, вызванных изменением законодательства в налоговой, таможенной и других сферах, а также в части соответствующего изменения сроков исполнения договора в случае изменения финансирования по годам. Внесение такого изменения допускается по прошествии одного года действия договора и не более одного раза в год; 7) в части уменьшения или увеличения суммы долгосрочного договора о закупках на поставку товаров, заключенного с отечественным товаропроизводителем, вследствие уменьшения или увеличения цены товара, вызванного значительным изменением стоимости сырья и(или) комплектующих, необходимых для производства товара, а также тарифов, влияющих на ценообразование товара. Внесение такого изменения допускается по взаимному согласию сторон на основании ценового маркетингового заключения Уполномоченного органа по вопросам закупок в лице дочерней организации, определенной Правлением Фонда, по прошествии одного года действия договора и не более одного раза в полугодие. 8) в части уменьшения или увеличения суммы договора о закупках, связанной с изменением цен, тарифов, сборов и платежей, установленных законодательством Республики Казахстан. Такое изменение заключенного договора о закупках товаров, 14 работ, услуг допускается в пределах сумм, предусмотренных для приобретения данных товаров, работ, услуг в плане закупок. 68. Не допускается вносить в проект либо заключенный договор о закупках изменения, которые могут изменить содержание условий проводимых (проведенных) закупок и/или предложения, явившегося основой для выбора поставщика, по иным основаниям не предусмотренным пунктами 66 и 67 настоящей Тендерной документации. 69. Потенциальные поставщики (поставщики) вправе обжаловать действия и решения, принимаемые в процессе закупок руководителями и членами органов Заказчика, а также иных лиц, включая членов тендерной, экспертной комиссий, эксперта. 70. Жалобы могут быть направлены для рассмотрения Заказчику, АО «СамрукҚазына». 10. Разъяснение положений Тендерной документации 71. При проведении тендера Заказчик вправе организовать встречу с потенциальными поставщиками, получившими Тендерную документацию, для разъяснения положений Тендерной документации. Дата, время и место проведения встречи указаны в преамбуле Тендерной документации. По итогам встречи с участниками тендера секретарь тендерной комиссии оформляет протокол, который должен содержать: 1) наименование, юридический адрес, контактные телефоны потенциальных поставщиков и их уполномоченных представителей с указанием фамилий, имен, отчеств присутствовавших на встрече, на основании документов, подтверждающих право представителя потенциального поставщика участвовать во встрече; 2) информацию о работниках Заказчика с указанием должности и фамилий, имен, отчеств, участвовавших во встрече; 3) затронутые вопросы и ответы на них в рамках Тендерной документации; 4) сведения о необходимости внесения изменений и/или дополнений в Тендерную документацию. Протокол подписывается работниками Заказчика, присутствовавшими на встрече, и в течение 2 (двух) рабочих дней со дня проведения встречи направляется всем потенциальным поставщикам, получившим Тендерную документацию. 72. Потенциальный поставщик, получивший Тендерную документацию, вправе обратиться с письменным запросом о разъяснении положений Тендерной документации в срок не позднее 7 (семи) календарных дней до истечения окончательного срока приема Заявок. Заказчик обязан не позднее 3 (трех) рабочих дней с момента поступления запроса ответить на него и без указания на то, от кого поступил запрос, направить данное разъяснение всем потенциальным поставщикам, получившим Тендерную документацию. 11. Изменение Тендерной документации 73. Изменения и дополнения в Тендерную документацию вносятся Заказчиком в установленном порядке в срок не позднее 5 (пяти) календарных дней до истечения окончательного срока представления Заявок. При этом окончательный срок предоставления Заявок продлевается не менее чем на 10 (десять) календарных дней. Об изменениях и дополнениях Тендерной документации и изменённом сроке представления Заявок Заказчик уведомляет всех потенциальных поставщиков, получивших Тендерную документацию, в течение 2 (двух) рабочих дней со дня утверждения изменений и дополнений в Тендерную документацию и посредством размещения соответствующей информации и Тендерной документации с внесенными изменениями на интернет-ресурсе Заказчика и на интернет-ресурсе, определенном Фондом. Приложения: 15 1. 2. услуг 3. 4. 5. 6. Перечень закупаемых товаров, работ, услуг Техническая спецификация (техническое задание) закупаемых товаров, работ, Форма Заявки потенциального поставщика для юридических лиц Форма ценового предложения Форма банковской гарантии в обеспечение заявки Проект договора о закупках товаров/ услуг 16 Приложение 1 к Тендерной документации по закупу сетевого оборудования и услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения (4G) на базе технологии LTE «под ключ» Наименование заказчика: АО «АЛТЕЛ». N лотов Наименование товаров, работ и услуг (по лотам) Краткая характеристика (описание) товаров, работ и услуг* Ед. изм. Количе ство (объем потреб -ности) Срок поставки товаров, выполнения работ, оказания услуг №1 Закуп сетевого оборудования, услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения (4G) на базе технологии LTE "под ключ" Закуп сетевого оборудования, услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения (4G) на базе технологии LTE "под ключ" Компл ект оборуд ования и услуги 1 не позднее 30.11.2012 Место приемапередачи товаров, выполненн ых работ и оказанных услуг DAP /DDP Алматы и Астаны (объекты установки) согласно условиям Incoterms 2010 *Полное описание и характеристика товаров, работ и услуг указывается в техническом задании. Президент АО «АЛТЕЛ» _____________________________________Сауранбеков М.Т. М. П 17 Приложение 2 к Тендерной документации по закупу сетевого оборудования и услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения (4G) на базе технологии LTE «под ключ» ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА ТЕНДЕР Алматы, 2012 г. 18 Оглавление 1. ОПРЕДЕЛЕНИЯ И АББРЕВИАТУРЫ 2. ОБЩИЕ СВЕДЕНИЯ 2.1. ЦЕЛИ И ЗАДАЧИ 2.2. ПРЕДМЕТ ТЕНДЕРА 2.3. ОБЩИЕ ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ РЕШЕНИЯМ 2.4. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ РАБОТ И УСЛУГ 3. ОБЪЕМ ПОСТАВЛЯЕМОГО ПО ТЕНДЕРУ ОБОРУДОВАНИЯ 3.1. ОБЪЕМ ПОСТАВЛЯЕМОГО ОБОРУДОВАНИЯ ЕРС 3.2. ОБЪЕМ ПОСТАВЛЯЕМОГО ОБОРУДОВАНИЯ RAN 3.3. ОБЪЕМ ПОСТАВЛЯЕМОГО ОБОРУДОВАНИЯ РРЛ 3.4. ОБЪЕМ ПОСТАВЛЯЕМОГО АБОНЕНТСКОГО ОБОРУДОВАНИЯ 3.5. СПЕЦИАЛЬНЫЕ ТРЕБОВАНИЯ К ЦЕНОВОМУ ПРЕДЛОЖЕНИЮ ПОСТАВЩИКА 3.6. ОБЯЗАТЕЛЬНЫЕ ТРЕБОВАНИЯ ПО СИСТЕМЕ ЛИЦЕНЗИРОВАНИЯ ДЛЯ ВКЛЮЧЕННОГО В ПРЕДЛОЖЕНИЕ ОБОРУДОВАНИЯ 4. ОБЩИЕ ХАРАКТЕРИСТИКИ СЕТИ LTE 4.1. ОБЩИЕ ТРЕБОВАНИЯ К ОБОРУДОВАНИЮ СЕТИ LTE 4.2. ОБЩИЕ ТРЕБОВАНИЯК АРХИТЕКТУРЕ ПОСТРОЕНИЯ СЕТИ LTE 4.3. ОБЩИЕ ТРЕБОВАНИЯ К ИСПОЛЬЗУЕМЫМ ЧАСТОТНЫМ ДИАПАЗОНАМ 4.4. ОБЩИЕ ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ СЕТИ LTE 4.5. ТРЕБОВАНИЯ К СИНХРОНИЗАЦИИ 5. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К EPC 5.1. ОБЩИЕ ТРЕБОВАНИЯ К EPC 5.2. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ММЕ 5.3. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К UDC 5.4. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К S-GW/P-GW 5.5. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К DPI 5.6. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К PCRF 5.7. ТРЕБОВАНИЯ К ETHERNET КОММУТАТОРАМ 5.8. ТРЕБОВАНИЯ К ОБОРУДОВАНИЮ FIREWALL 5.9. ТРЕБОВАНИЯ К МАРШРУТИЗАТОРАМ EPC 5.10. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ ЭЛЕКТРОПИТАНИЯ EPC 6. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К RAN 6.1. ОБЩИЕ ТРЕБОВАНИЯ К RAN 6.2. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К eNodeB 6.3. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ ЭЛЕКТРОПИТАНИЯ eNodeB 6.4. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ОБОРУДОВАНИЮ РРЛ 6.5. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ШКАФАМ / КОНТЕЙНЕРАМ 6.6. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К МЕТАЛЛОКОНСТРУКЦИЯМ И МАТЕРИАЛАМ 7. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К OSS 7.1. ТРЕБОВАНИЯ К СИСТЕМЕ OSS 7.2. ИДЕОЛОГИЯ ПОСТРОЕНИЯ СИСТЕМЫ OSS 8. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СОРМ 19 9. ОБЩИЕ ЭКСПЛУАТАЦИОННЫЕ ТРЕБОВАНИЯ 9.1. ТРЕБОВАНИЯ К НАДЕЖНОСТИ 9.2. ТРЕБОВАНИЯ К ОБЕСПЕЧЕНИЮ ЗАПАСНЫМИ ЧАСТЯМИ 9.3. ТРЕБОВАНИЯ К ГАРАНТИЙНОМУ И ПОСТГАРАНТИЙНОМУ ОБСЛУЖИВАНИЮ 9.4. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ 9.5. ДОПОЛНИТЕЛЬНЫЕ ТРЕБОВАНИЯ 10. ТРЕБОВАНИЯ К ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ И РЕМОНТУ 11. ТАБЛИЦА СООТВЕТСТВИЯ ТЕХНИЧЕСКИМ ТРЕБОВАНИЯМ КОНКУРСА 12. ТАБЛИЦА ЦЕН 20 1. ОПРЕДЕЛЕНИЯ И АББРЕВИАТУРЫ В настоящих аббревиатуры: технических требованиях используются следующие определения и LTE (Long-Term Evolution) – принципы развития сетей беспроводной ШПД в долговременной перспективе, предложенные некоммерческой организацией 3GPP. Аббревиатура LTE широко используется применительно к сетям, являющимся дальнейшим развитием сетей поколения 3G, а также к соответствующим спецификациям / стандартам 3GPP. RAN (Radio Access Network) – беспроводная сеть, обеспечивающая доступ абонентов к услугам передачи данных (ПД). EPC (Evolved Packed Core) – ядро сети LTE. eNodeB – базовая станция; узел радиосети LTE. Является интерфейсом между абонентом, запрашивающим сервис ШПД из пределов зоны радио-покрытия базовой станции, и ядром сети (EPC). BBU – (Base Band Unit) компонент eNodeB «распределенной» конструкции, размещаемый на удалении от антенной системы в шкафу / контейнере. RRU – (Remote Radio Unit) компонент eNodeB (вынесенный радио-модуль), размещаемый вблизи антенной системы; управление и электропитание RRU организуется соответствующими кабельными соединениями с BBU и системой электропитания, размещенных в шкафу / контейнере. Site – объект сети (Сайт), на котором проведен комплекс необходимых мероприятий, обеспечивающих установку и ввод в эксплуатацию основного eNodeB и дополнительного оборудования. DCCA - приложение Diameter Credit-Control - сетевой протокол, используемый для внедрения кредитного контроля в режиме реального времени для различных сервисов, предоставляемых конечному пользователю. Стандарт IETF (Internet Engineering Task Force), определенный в RFC 4006. FBC – Flow Bearer Charging. Стандартизация управления политиками в 3GPP-R6 возможность динамической смены правил тарификации. AVP - attribute value pairs - метод формирования информации, относящейся к протоколу Diameter message. AVP - это атрибут RADIUS. Некоторые AVPs используются на базе протокола Diameter; другие AVPs предназначены для приложения Diameter (e.g. NASREQ); тогда как иные могут быть использованы высокоуровневой конечной системой приложений с использованием протокола Diameter. SPR – Subscriber Profile Repository (хранилище профилей абонентов). UDC (User Data Convergency) - конвергентная база данных UDR (User Data Repository) – хранилище данных пользователя HSS (Home Suscriber Server) – сервер абонентских данных KPI (Key Performance Indicators) – ключевые показатели производительности и качества Трансмиссия – физические / логические каналы связи между оборудованием eNodeB и EPC. Сеть – в пределах настоящего документа обозначает сеть LTE (в целом или в отношении отдельной подсистемы – в зависимости от контекста). ЗИП - запасные части, инструменты и принадлежности БД – база (базы) данных 21 2. ОБЩИЕ СВЕДЕНИЯ Настоящий документ является неотъемлемой частью Тендерной документации и устанавливает технические требования к комплексу Оборудования и Услуг предъявляемых для построения сети мобильного широкополосного доступа стандарта LTE (Long-Term Evolution) в гг.Алматы и Астана в полосе частот 1800МГц – первая фаза Проекта построения сети мобильного широкополосного доступа стандарта LTE в Казахстане. 2.1. ЦЕЛИ И ЗАДАЧИ 2.1.1. Цели Строительство сетевой и информационной инфраструктуры для предоставления услуг мобильного широкополосного доступа в городах Алматы, Астана. Внедрение услуг мобильного широкополосного доступа с высокими качественными показателями. 2.1.2. Задачи Строительство сетей мобильного широкополосного доступа стандарта LTE стандарта 3GPP R9/R10 в городах Алматы и Астана для массового предоставления услуг мобильного широкополосного доступа – I этап построения сети мобильного широкополосного доступа стандарта LTE на территории Республики Казахстан. Организация пакетного ядра EPC в г.Алматы для сетей мобильного широкополосного доступа стандарта LTE для подключения к пакетным сервисам, включая доступ в Интернет. Организация транспортной среды для передачи данных сети мобильного широкополосного доступа стандарта LTE и пакетного ядра EPC. Организация конвергентной базы данных (UDC) в г.Алматы. Интеграция с системами Заказчика для предоставления услуг мобильного широкополосного доступа, в том числе с системами управления абонентами и услугами, биллинговой системой. Внедрение систем управления и мониторинга (OSS). Организация СОРМ для абонентов мобильного широкополосного доступа. Обеспечение заданного уровня покрытия и качества сети LTE в соответствии с KPI 2.2. ПРЕДМЕТ ТЕНДЕРА Предметом настоящего тендера по закупу сетевого оборудования и услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения “под ключ” является следующее: Табл.2.1. № п.п. Наименование 1. Поставка оборудования и материалов, программного обеспечения, лицензий на условиях DAP/DDP (объекты установки), в том числе: 1.1. Оборудование, программное обеспечение и лицензии для организации пакетного ядра EPC в г.Алматы: MME (mobility management entity – узел управления мобильностью) UDC (user data convergence – конвергентная база данных) S-GW (serving gateway – обслуживающий шлюз) 1.1.2. 1.1.3. 1.1.4. Ед.изм Кол-во компл. 1 компл. 1 компл. 1 компл. 1 Примечание 22 1.1.5. 1.1.6. 1.1.7. 1.1.8. 1.1.9. 1.1.10. 1.1.11 1.1.12. 1.1.13. 1.1.14. 1.1.15. 1.1.16. 1.2. 1.2.1. 1.2.1.1. 1.2.1.2. 1.2.2. 1.2.3. 1.3. 1.3.1. 1.3.1.1. 1.3.1.2. 1.3.2. 1.3.3. 1.4. P-GW (packet data network gateway – пакетный шлюз) DPI (deep packet inspection – анализатор трафика) PCRF (policy and charging rules function – узел управления политик) OSS (operation support system – система управления сети) Ethernet-коммутаторы(IP коммутаторы) FireWall(межсетевой экран) Маршрутизаторы EPC Система гарантированного электропитания DC и AC и аккумуляторные батареи Дизель-генератор Расходные материалы, необходимые для строительства пакетного ядра EPC Программное обеспечение и лицензии Запасные части, инструменты, принадлежности (ЗИП) в соответствии с рекомендациями производителя к каждому типу поставляемого оборудования Оборудование, программное обеспечение и лицензии, необходимые для строительства RAN в г. Алматы с заданными KPI: Комплект eNodeB, в том числе: компл. 1 компл. 1 компл. 1 компл. 1 компл. компл. компл. компл. 1 1 1 1 компл. компл. 1 1 компл. компл. 1 1 компл. 201 компл. компл. компл. 48 153 компл. - компл. 150 Indoor исполнения Outdoor исполнения Запасные части, инструменты, принадлежности (ЗИП) в соответствии с рекомендациями производителя к каждому типу поставляемого оборудования Материалы, необходимые для строительства инфраструктуры для размещения базовых станций компл. компл. компл. 18 132 1 компл. - Оборудование, программное обеспечение и компл. 90 Indoor исполнения Outdoor исполнения Запасные части, инструменты, принадлежности (ЗИП) Материалы, необходимые для строительства инфраструктуры для размещения базовых станций Оборудование, программное обеспечение и лицензии, необходимые для строительства RAN в г. Астана с заданными KPI: Комплект eNodeB, в том числе: Минимальное количество*. Потенциальный поставщик в тендерной заявке должен указать необходимое количество для выполнения заданных KPI. Перечень необходимых материалов определяется потенциальным поставщиком по результатам подготовки проектно-сметной документации для выбранного объекта Минимальное количество*. Потенциальный поставщик в тендерной заявке должен указать необходимое количество для выполнения заданных KPI. Перечень необходимых материалов определяется потенциальным поставщиком по результатам подготовки проектно-сметной документации для выбранного объекта Количество пролетов точка- 23 точка лицензии, расходные материалы и ЗИП, необходимые для строительства транспортной сети РРЛ в гг. Алматы и Астана 2. Работы и услуги по строительству сети в гг. Алматы и Астана “под ключ”, в том числе: 2.1. Услуги по планированию, строительству, монтажу и пуско-наладке, интеграции, сдаче в эксплуатацию сети LTE в гг. Алматы и Астана “под ключ” Услуги по гарантийной поддержке поставляемого оборудования, программного обеспечения и лицензий Услуги по обучению персонала Заказчика Услуги по техническому сопровождению сети после запуска в эксплуатацию (baby seating) 2.2. 2.3. 2.4. услуга 1 услуга 1 услуга услуга 1 1 * Указано ориентировочное количество базовых станций, обеспечивающих покрытие радиосети в пределах обозначенных Заказчиком границ городов Алматы и Астана (Приложение 2). Это количество определено по результатам номинального радио-планирования сети и должно рассматриваться потенциальным Поставщиком, как минимальное количество, обязательное для включения в техническое и ценовое предложение. В то же время Поставщик обязан гарантировать достижения необходимого уровня качества и емкости сети LTE в двух городах согласно заданным Заказчиком KPI (Таблица 2.3. ниже). Показатели качества KPI должны быть гарантированы как в ходе Приемки в эксплуатацию, так и в период эксплуатации сети в рамках определенной в тендерной документации необходимой емкости сети и количества абонентов. Поставщик имеет право при подаче тендерных предложений увеличить количество базовых станций и связанное с этим количество материалов, работ и услуг, если считает, что указанное минимально необходимое количество базовых станций eNodeB недостаточно для обеспечение покрытия с заданными KPI. Изменение количества оборудования, работ и услуг после подачи тендерных предложений не допускается. В случае, если показатели покрытия и качества KPI не достигнуты в ходе Приемки в эксплуатацию и/или в период эксплуатации сети, в рамках и объемах определенных в тендерном предложении поставщика, рассчитанных для поддержания необходимой емкости сети и количества абонентов, требуемых тендерной документацией, поставщик обязан за свой счет допоставить и установить необходимое количество дополнительного оборудования и программного обеспечения, для приведения в соответствие фактических уровней с заданными уровнями показателей покрытия и качества KPI. 2.3. ОБЩИЕ ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ РЕШЕНИЯМ: При формировании технических решений для настоящего тендера, потенциальный поставщик должен принимать в расчет: 2.3.1. Прогноз по активной абонентской базе в гг. Алматы и Астана, приведенный в Табл.2.2. При этом предлагаемые технические решения должны быть достаточны для обеспечения потребностей на конец 2016 года без дополнительных затрат со стороны Заказчика. Табл.2.2. 2012 г. 2013 г. 2014 г. 2015 г. 2016 г. 15 000 55 000 105 000 165 000 225 000 Пользователи 15 000 40 000 50 000 60 000 60 000 Прирост 10 000 35 000 65 000 110 000 150 000 Алматы 5 000 20 000 40 000 55 000 75 00 Астана 2.3.2. Емкость системы EPC: предложение должно включать аппаратное и программное обеспечение емкости, необходимое для обслуживания минимум 300 000 активных абонентов с возможностью расширения до 4 000 000 активных абонентов, а также необходимый пакет 24 лицензий для обеспечения минимум 300 000 активных абонентов (в соответствии с требованиями по лицензированию, изложенными в п. 3.6); количество одновременных зарегистрированных пользователей (SAU) 150 000 и одновременных активных сессий 60 000. 2.3.3. Заданные целевые KPI сети приведены в Табл.2.3. Табл.2.3. # 1 2 3 4 5 6 7 8 9 10 Название KPI Cell availability OSS (Operation and Support System) availability Packet switched Call Setup Success Rate (CSSR) Packet switched Call Drop Rate (CDR) Packet Switched Call Handover Success Rate RRC Connection Setup Success Rate E-RAB Setup Success Rate Average Throughput per Resource Block Intra-Frequency Handover Success Rate Maximum User Throughput on DL in test environment Единица Значен Категория измерен ие ия % >99.8 Статистика % >99 Статистика % >99 Статистика % <0.75 Статистика % >99 Статистика % >99.5 Статистика % >99.5 Статистика Mbps >0.5 Статистика % >99 Статистика >=140 Измерение в лаборатори и Mbps 11 Maximum User Throughput on UL in test environment Mbps >=48 Измерение в лаборатори и 12 Average User Throughput on DL in drive-test Mbps >=35 Драйв-тест 13 Average User Throughput on UL in drive-test Mbps >=12 Драйв-тест 14 Average User Throughput on DL in drive-test on cell edge (with probability 95%) Mbps >=5 Драйв-тест Комментарии Измерение в лаборатории, с терминалом категории 4, с шириной канала в 20 MHz, 2x2 MIMO, в статическом режиме, с 1 пользователем в соте Измерение в лаборатории, с терминалом категории 4, с шириной канала в 20 MHz, 2x2 MIMO, в статическом режиме, с 1 пользователем в соте Согласованный маршрут драйв-теста, с терминалом категории 4, с шириной канала в 20 MHz, 2x2 MIMO, в ненагруженной сети Согласованный маршрут драйв-теста, с терминалом категории 4, с шириной канала в 20 MHz, 2x2 MIMO, в ненагруженной сети Согласованный маршрут драйв-теста, с терминалом категории 4, с шириной канала в 20 MHz, 2x2 MIMO, в ненагруженной сети 25 15 Average User Throughput on UL in drive-test on cell edge (with probability 95%) 17 Latency - Ping Round Trip Time (RTT) Packet switched Call Setup Success Rate (CSSR) 18 Packet switched Call Drop Rate (CDR) 16 Mbps >=0.5 Драйв-тест msec <20 Драйв-тест % >98.5 Драйв-тест % <1.5 Драйв-тест msec <100 Драйв-тест % >98 Драйв-тест % >98 Драйв-тест 21 Idle to Active Transition Time Packet Switched Call Intra-Frequency Handover Success Rate EPS Bearer Activation Success Rate (PDP context) 22 Reference Symbol Received Quality (RSRQ) Ratio % >95 Драйв-тест 23 Reference Symbol Received Power (RSRP) Ratio outdoor % >95 Драйв-тест 24 Reference Symbol Received Power (RSRP) Ratio indoor % >85 Драйв-тест 19 20 Согласованный маршрут драйв-теста, с терминалом категории 4, с шириной канала в 20 MHz, 2x2 MIMO, в ненагруженной сети Согласованный маршрут драйв-теста, с терминалом категории 4, с шириной канала в 20 MHz, 2x2 MIMO, в ненагруженной сети, не менее 100 Ping 32 byte Согласованный маршрут драйв-теста, с терминалом категории 4 Согласованный маршрут драйв-теста, с терминалом категории 4 Согласованный маршрут драйв-теста, с терминалом категории 4 Согласованный маршрут драйв-теста, с терминалом категории 4 Согласованный маршрут драйв-теста, с терминалом категории 4 Согласованный маршрут драйв-теста, с терминалом категории 4, с внешней антенной. Значение предела должно быть выработано при планировании Link Budget Согласованный маршрут драйв-теста, с терминалом категории 4, с внешней антенной. Значение Link Budget берется по уровню -97 dBm Согласованный маршрут драйв-теста, с терминалом категории 4, с внешней антенной. Значение Link Budget берется по уровню -78 dBm 2.3.4. Строительство сети в рамках настоящего тендера может рассматриваться Заказчиком в качестве первого этапа по строительству сети в соответствии со следующими лицензионными обязательствами, но не является обязательством Заказчика по покупке оборудования потенциального поставщика на последующих этапах: 2.3.4.1. Используя выделенные частоты, обеспечить покрытие мобильной связью четвертого поколения стандарта LTE (4G): До 30 ноября 2012 года в городах Астана и Алматы; 26 До 1 января 2014 года во всех областных центрах Республики Казахстан; До 1 января 2015 года во всех населенных пунктах с численностью населения от 50 тысяч и более; До 1 января 2018 года во всех районных центрах. 2.3.5. Строительство сети в рамках настоящего тендера может рассматриваться Заказчиком в качестве первого этапа по строительству сетей 2G/3G/4G, но не является обязательством Заказчика по покупке оборудования потенциального поставщика на последующих этапах. 2.3.6. Потенциальный поставщик в тендерной заявке должен предоставить подробный график реализации проекта. График реализации должен включать следующие основные положения и даты реализации: Табл.2.4. № пп 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. График реализации проекта. Виды работ Подписание Договора поставки оборудования и выполнения услуг на условиях «под ключ» Разработка технического дизайна сети, планирование RAN и EPC, выбор мест для установки сайтов Заключение договоров аренды по сайтам Обследование, проектная документация, подготовка сайтов к монтажу оборудования Производство и комплектация оборудования партиями Поставка и таможенная очистка оборудования партиями Доставка оборудования к местам установки партиями Монтаж оборудования и загрузка программного обеспечения Интеграция с: биллинговой системой и системой управления абонентами и услугами, Интернет, IP VPN, iD TV, iDPhone, СОРМ Тестирование и предварительная приемка сети Устранение замечаний Тестирование и окончательная приемка сети Запуск в эксплуатацию Дата начала 27.06.2012 Дата окончания 10.07.2012 10.07.2012 10.08.2012 10.07.2012 10.07.2012 01.08.2012 01.09.2012 10.07.2012 22.08.2012 01.09.2012 01.09.2012 10.09.2012 22.09.2012 01.10.2012 15.10.2012 01.10.2012 01.11.2012 01.11.2012 20.11.2012 10.11.2012 25.11.2012 25.11.2012 30.11.2012 30.11.2012 2.3.7. Отдельным письмом потенциальный поставщик должен подтвердить согласие и возможность выполнения проекта в указанные в Табл.2.4. сроки и запуск сети в коммерческую эксплуатацию в гг. Алматы и Астана в срок до 30.11.12. 2.4. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОБЪЕМУ РАБОТ И УСЛУГ 2.4.1. Тендерное предложение потенциального поставщика должно содержать следующие сервисные работы и услуги по построению сети в гг.Алматы и Астана “под ключ”: 2.4.1.1. Создание со стороны потенциального поставщика “команды проекта”, в которую должны быть включены необходимые для выполнения проекта ресурсы соответствующей квалификации с постоянным местонахождением на территории Республики Казахстан; 2.4.1.2. Услуги по управлению Проектом (Project Management), в соответствии с международными стандартами; 27 2.4.1.3. Услуги по разработке подробного технического проекта сети, проектов монтажа оборудования EPC и RAN, рабочей документации; 2.4.1.4. Услуги по радио-планированию сети, планированию емкости. Потенциальный поставщик за свой счет должен обеспечить необходимые цифровые карты местности и программно-аппаратные комплексы для радио-планирования сети, которые должны быть переданы Заказчику безвозмездно. 2.4.1.5. Услуги по определению потенциальных мест для размещения сайтов, с учетом и максимальным использованием существующих сайтов Заказчика (Приложение 1); 2.4.1.6. Услуги по поиску площадок для размещения базовых станций, проведению предварительного обследования, подготовке предварительных проектов, заключению договоров аренды от имени Заказчика; 2.4.1.7. Услуги по планированию транспортной сети, в том числе с использованием РРЛ до отдельных eNodeB, с предоставлением детального расчета необходимой пропускной способности; 2.4.1.8. Услуги по подготовке проектной документации по размещению оборудования на площадках, согласование проектной документации с Заказчиком и Арендодателем и в случае необходимости с регулирующими органами; 2.4.1.9. Подготовка проектной документации и получение санитарных паспортов на радиооборудование; 2.4.1.10. Услуги по строительству инфраструктуры для размещения оборудования базовых станций, включая при необходимости сооружение помещений (установку шелтеров/выгородок), организацию линий электропитания (включая, при необходимости, получение технических условий на подключение к электрическим сетям), защитного заземления, молниезащиты, устройство контуров заземления, организацию сооружений для размещения антенно-фидерных устройств; 2.4.1.11. Услуги по аренде складских помещений для временного хранения оборудования за счет потенциального поставщика. 2.4.1.12. Проведение работ по переупаковке поставляемого оборудования и материалов на складах (при необходимости), доставка оборудования к месту монтажа, учет смонтированного оборудования и материалов, предоставление Заказчику расходных ведомостей по использованным материалам. 2.4.1.13. Монтаж поставляемого оборудования и материалов в соответствии с проектной документацией. Корректировка проектной документации после завершения монтажа (при необходимости); 2.4.1.14. Проведение работ по настройке, конфигурации, пуско-наладке, интеграции оборудования на местах установки; 2.4.1.15. Проведение работ по интеграции с транспортными сетями, существующими сетями передачи данных, системами биллинга, системами управления абонентами и услугами, системами управления сетями, системами сбора статистической информации. 2.4.1.16. Проведение работ по интеграции с существующими сервисами: Интернет, IP VPN, iD TV и iD Phone. 2.4.1.17. Проведение работ по оптимизации сети, достижение заданных ключевых показателей качества, пропускной способности и эффективности. Потенциальный поставщик должен за свой счет обеспечить необходимые приборы и инструменты для проведения указанных работ; 2.4.1.18. Проведение приемочных испытаний совместно с Заказчиком; 2.4.1.19. Проведение сертификации оборудования в соответствии с законодательством Республики Казахстан; 28 2.4.1.20. Услуги по интеграции оборудования сети с системами обеспечения СОРМ и получение сертификата соответствия требованиям в соответствии с законодательством Республики Казахстан; 2.4.1.21. Услуги по подготовке статистических отчетов, содержащих анализ ключевых показателей эффективности и качества работы сети и автоматизации их формирования; 2.4.1.22. Сдача сети в эксплуатацию; 2.4.1.23. Услуги по технической поддержке и управлению сетью в течении гарантийного периода (baby seating) с привлечением персонала имеющего соответствующую сертификацию от производителя используемого оборудования; 2.4.1.24. Услуги по круглосуточной (24x7x365) технической поддержке сети со стороны центра поддержки потенциального поставщика в течении гарантийного и послегарантийного периода ; 2.4.1.25. Услуги по Ремонту и Замене неисправных модулей в течение Гарантийного и Постгарантийного периода, включая оборудование третьих производителей; 2.4.1.26. Обучение обслуживающего персонала Заказчика (включая обучение на специализированных курсах, а также on-site обучение); 2.4.1.27. Обеспечение необходимым объемом ЗИП для гарантирования бесперебойной работы всех элементов сети, включая оборудование третьих производителей. 2.4.2. Тендерное предложение Поставщика должно содержать весь комплекс работ и услуг, необходимых для реализации проекта “под ключ”. Поставщик имеет право при подаче тендерных предложений дополнить список необходимых работ и услуг. Изменение количества и стоимости работ и услуг после подачи тендерных предложений не допускается. Стоимость дополнительных работ и другие расходы, необходимые для выполнения проекта «под ключ», но не включенные в ценовое тендерное предложение, Поставщик выполняет за свой счет без дополнительной оплаты. 2.4.3. Потенциальный поставщик вправе привлекать к выполнению работ субподрядчиков, при этом ответственность за соблюдение сроков и качества выполняемых работ и услуг, организацию взаимодействия с Заказчиком, приемку работ и услуг у субподрядчиков и сдачу сети Заказчику несет потенциальный поставщик. Заказчик вправе потребовать замену субподрядчика или персонала Поставщика в случае не соответствия качества услуг и сроков их выполнения требованиям Заказчика. 2.4.4. 29 3. ОБЪЕМ ПОСТАВЛЯЕМОГО ПО ТЕНДЕРУ ОБОРУДОВАНИЯ Поставляемое оборудование, описанное ниже, должно содержать в комплекте поставки все необходимые материалы и инструменты для проведения монтажно-инсталляционных работ и запуска в эксплуатацию. 3.1. ОБЪЕМ ПОСТАВЛЯЕМОГО ОБОРУДОВАНИЯ EPC В рамках данного тендера, планируется построение общего на два города ядра сети (EPC), которое будет установлено в Алматы. Описание элементов сети приведено в п.5. EPC должен состоять из следующих функциональных элементов, программного обеспечения и соответствующих лицензий: 3.1.1. MME (mobility management entity – узел управления мобильностью). 3.1.2. UDC (user data convergence – конвергентная база данных) 3.1.3. S-GW (serving gateway – обслуживающий шлюз). 3.1.4. P-GW (packet data network gateway – пакетный шлюз). 3.1.5. DPI (deep packet inspection – анализатор трафика). 3.1.6. PCRF (policy and charging rules function – узел управления политик). 3.1.7. OSS (operation support system – система управления сети). 3.1.8. Ethernet коммутаторы (IP коммутаторы). 3.1.9. FireWall(межсетевой экран). 3.1.10. Маршрутизаторы EPC. 3.1.11. Система гарантированного электропитания с аккумуляторными батареями, дизельгенератор. 3.2. ОБЪЕМ ПОСТАВЛЯЕМОГО ОБОРУДОВАНИЯ RAN Территория развертывания RAN – г.Алматы, г.Астана, и их ближайшие пригороды. Количество устанавливаемых сайтов приведено в Табл.2.1. Установку eNodeB планируется производить с использованием существующих объектов Заказчика и новых объектов. 3.2.1. Все eNodeB должны строиться на оборудовании одного типа, имеющего распределенную структуру построения. 3.2.2. Конфигурация поставляемых eNodeB должна обеспечивать трехсекторную конфигурацию, 2x2 MIMO и пропускную способность не менее DL 150Мбит/с, UL 50Мбит/с на сектор; суммарная пропускная способность eNodeB должна быть не менее DL 300Мбит/с, UL 100Мбит/с. 3.2.3. eNodeB должны поставляться в исполнениях: для установки в помещении и для установки вне помещения. Подробные требования к eNodeB приведены в п.6. 3.2.4. Комплект eNodeB для установки в помещении должен быть размещен в стойке без климатической системы и иметь в своем составе систему питания с аккумуляторными батареями. В стойке должно быть предусмотрено свободное место не менее 2U для установки оборудования оптической транспортной сети или оборудования РРЛ. 3.2.5. Комплект eNodeB для установки вне помещения должен иметь в составе систему электропитания с аккумуляторными батареями и размещаться в шкафу/контейнере, обеспечивающем заданный климатический режим и антивандальную защиту оборудования. В шкафу/ контейнере должно быть предусмотрено свободное пространство размером не менее 2U для установки оборудования оптической транспортной сети или оборудования РРЛ. 3.2.6. Состав комплекта eNodeB 30 3.2.6.1. Один комплект поставляемого eNodeB должен включать все компоненты, необходимые для построения сайта и содержать: 3.2.6.2. Основное оборудование: BBU, RRU, АФУ (антенны, джамперы, сплитеры, материалы) ; 3.2.6.3. Дополнительное оборудование: систему электропитания AC/DC, датчики температуры, датчики системы безопасности, датчики пожарной сигнализации и другое; 3.2.6.4. Стойку для размещения оборудования eNodeB; 3.2.6.5. Кабельную продукцию: фидера, электрические и оптические кабели; 3.2.6.6. Металлоконструкции, шины заземления, молниеотводы и расходные материалы; 3.2.6.7. Программное обеспечение и лицензии; 3.2.6.8. ЗИП; 3.2.6.9. Комплекс услуг под ключ; 3.2.6.10. Инструменты для обслуживания оборудования eNodeB; 3.2.6.11. Необходимый комплект документации. 3.3. ОБЪЕМ ПОСТАВЛЯЕМОГО ОБОРУДОВАНИЕ РРЛ 3.3.1. Для организации транспорта до eNodeB, до которых на момент запуска не будет возможности организации оптического транспорта, должны быть поставлены РРЛ (требования к оборудованию РРЛ описано в п.6.4). 3.3.2. Поставщик должен поставить РРЛ пролеты для обеспечения транспортной сети для 90 сайтов. 3.4. ОБЪЕМ ПОСТАВЛЯЕМОГО АБОНЕНТСКОГО ОБОРУДОВАНИЯ В рамках данного тендера должно быть поставлено абонентское оборудование для целей тестирования сети. Общее количество поставляемых абонентских устройств должно составлять не менее 300 экземпляров. Должны быть поставлены абонентские устройства следующих видов: 3.4.1. Смартфоны 20 шт. 3.4.2. Планшетные компьютеры 30 шт. 3.4.3. Роутеры (маршрутизаторы) 50 шт. 3.4.4. USB-модемы 200 шт. 3.5. СПЕЦИАЛЬНЫЕ ТРЕБОВАНИЯ К ЦЕНОВОМУ ПРЕДЛОЖЕНИЮ ПОСТАВЩИКА 3.5.1. Потенциальный Поставщик должен предоставить комплексное ценовое предложение по всем запрашиваемым в тендерной документации системам оборудования, услугам и работам. Неполные технические и ценовые предложения (включая также по причине отсутствия у Потенциального Поставщика части запрашиваемой продуктовой линейки), могут быть отклонены и исключены тендерной комиссией из дальнейшего рассмотрения. 3.5.2. Единичные цены (эффективные единичные цены с учетом всех предоставленных скидок) должны быть подтверждены как максимальный уровень цен для последующих Закупок для данного типа оборудования или аналогичного оборудования новых релизов аппаратного обеспечения. 3.5.3. Если какие-то компоненты систем, необходимые для полноценного функционирования сети, являющейся предметом данного тендера, не были включены в расчет конечной стоимости, потенциальный поставщик обязан поставить их в необходимом объеме и составе за свой счет без дополнительной оплаты. 3.5.4. Запасные части к оборудованию должны поставляться по ценам не выше стоимости аналогичных модулей, поставляемых в составе основных комплектов оборудования с учетом применения всех предоставленных финальных скидок. 31 3.5.5. Представленные потенциальным поставщиком единичные цены на комплекты оборудования, профессиональные услуги и работы с учетом финальных скидок должны быть действительны для осуществления заказа независимо от количества заказываемых единиц оборудования/работ. 3.5.6. Цены на новые типы оборудования, релизы или новые продуктовые линейки оборудования должны быть гарантированы потенциальным поставщиком не выше предшествующих типов оборудования, включенных в предложение по данному тендеру потенциального поставщика. 3.5.7. Единичные цены на аппаратную часть базовых станций (например, RRU) должны быть обеспечены потенциальным поставщиком на одинаковом уровне, независимо от применяемого диапазона частот (например, 1800Мгц или 800Мгц), а также загружаемого типа ПО или релиза версии ПО. 3.5.8. Для всех включенных в тендерное предложение систем оборудования потенциальный поставщик должен предоставить ценовое предложение стоимости технического обслуживания сети за один год пост-гарантийного обслуживания. Ценовое предложение должно включать как общую стоимость, так и детальную разбивку по единичным ценам за год пост-гарантийного облуживания каждой из систем/узлов сети. Техническое обслуживание должно обязательно включать в себя, но не ограничиваться, замену и ремонт неисправных модулей (включая таможенную очистку, логистику по отправке и получению из сервисного центра и все сопряженные с этим транспортные и др. расходы), поддержку 24/7, устранение аварий и решение проблемных кейсов в соответствии с требуемым и оговоренным с Заказчиком Соглашением об уровне услуг. В стоимость технического обслуживания включается также: предоставление новых релизов и версий программного обеспечения и сервисные работы по установке коррекций и модернизаций программного обеспечения, новых версий программного обеспечения по мере доступности на рынке. Для расчета стоимости технического обслуживания по системе за каждый год пост-гарантийного срока стоимость обслуживания за один сайт (RAN сайт или место установки узла UDR/HSS, MME, SGW, P-GW, DPI, PCRF и т.д.) должна умножаться на количество таких сайтов/географических мест установки. Стоимость обслуживания в расчете за один географический сайт должна быть фиксированной и не зависеть от емкости и лицензий установленного узла, состава установленного оборудования. В гарантийный срок обслуживание сети предоставляется в том же объеме, включая выполнение Соглашения об уровне обслуживания, без дополнительной оплаты. 3.5.9. Поставщик несет ответственность за расчет количества необходимых запасных частей по каждому типу оборудования в соответствии с предложенным временем ремонта и возврата (turnaround time) и установленными у потенциального поставщика нормами определения необходимых размеров пула запасных частей с учетом времени MTBF. Рассчитанное количество запасных частей (но не менее одной единицы каждого типа) должно быть включено в ценовое предложение. В последующем, в случае необходимости дополнительного объема запасных частей и/или невыполнения условий соглашения по уровню сервисного обслуживания, поставщик предоставляет дополнительные запасные части за свой счет без дополнительной оплаты. 3.6. ОБЯЗАТЕЛЬНЫЕ ТРЕБОВАНИЯ ПО СИСТЕМЕ ЛИЦЕНЗИРОВАНИЯ ДЛЯ ВКЛЮЧЕННОГО В ПРЕДЛОЖЕНИЕ ОБОРУДОВАНИЯ 3.6.1. Все поставляемое оборудование должно поставляться полностью лицензированным до максимальной физической емкости аппаратной части. Таким образом, Поставщик обязуется не устанавливать искусственные ограничения (программные или иные Hardware Activation Codes, Keys), которые могут ограничивать возможность использования данного оборудования в рамках максимальной физической емкости. (например, Заказчик имеет право использования полной мощности поставляемых 32 радио модулей RRU с характеристиками 2x60Вт, независимо от того, что минимальные требования в запрашиваемых конфигурациях было указано 2x40Вт); 3.6.2. Поставщик обязан включить в Базовый пакет программного обеспечения, поставляемый с оборудованием, полный пакет базовых и опциональных функций. При этом, опциональные функции последующих релизов программного обеспечения должны автоматически включаться в Базовый пакет ПО Заказчика по каждой системе. 3.6.3. Поставщик обязан предоставить прозрачную и простую систему лицензирования пакета программного обеспечения, основанную на применении только одного параметра (“cost driver”) для масштабирования емкости предложенных систем: 3.6.3.1. RAN – стоимость пакета лицензий рассчитывается на каждую отдельную технологию 4G (в последующем применимо для 3G/2G) на один сайт, имеющий отдельное географическое место установки (Basic SW package per technology per geo-site), независимо от количества используемых частотных диапазонов и входящих в состав оборудования радио или системных модулей. 3.6.3.2. MME, S-GW – по количеству одновременно подключенных абонентов мобильной сети передачи данных SAU (Simultaneously attached user); 3.6.3.3. P-GW, DPI – по количеству одновременных активных сессий kPDP; 3.6.3.4. UDR/HSS, PCRF – по среднему количеству уникальных активных пользователей (IMSI) в течение каждого дня месяца (количеству уникальных пользователей, инициировавших хотя бы одну успешную исходящую сессию передачи данных). Среднее кол-во уникальных активных пользователей в течение месяца рассчитывается путем усреднения дневных данных, используя тарификационные записи в биллингвой системе по успешным абонентским сессиям. Заказчик закупает расширение лицензий HSS на количество уникальных активных пользователей при превышении среднемесячных данных по использованию данной лицензии в течение 3-х последовательных месяцев. 3.6.3.5. РРЛ – в расчете на РРЛ пролет (независимо от используемой системы резервирования 1+0 или 1+1) и т.д 3.6.3.6. Системы управления и мониторинга сети не лицензируются отдельно и входят в состав соответствующих систем, указанных выше (кроме лицензионных продуктов третьих сторон для OSS, которые должны быть указаны в ценовом предложении отдельно). 3.6.3.7. Стоимость комплекта лицензий за единицу емкости по каждой системе должна рассматриваться независимо от используемого релиза программного обеспечения как максимальная цена, которая не подлежит увеличению в течение как минимум 5 лет с момента заключения контракта поставки по данному тендеру. 3.6.3.8. Контроль количества используемых лицензий программного обеспечения должен осуществляться по данным систем мониторинга и статистики при обоюдном участии Поставщика и Заказчика, но без установки лимитирующих ограничений (как указано в П. 12). Превышение количества используемых лицензий ни при каких условиях в рамках физической емкости оборудования не должно приводить к остановке функционирования системы или к ограничениям абонентского трафика. 3.6.4. Отсутствие подтверждения по одному из выше перечисленных пунктов разделов 3.5 и 3.6 может являться для тендерной комиссии основанием для отклонения предложения Потенциального Поставщика и исключения из дальнейшего рассмотрения и участия. 33 4. ОБЩИЕ ХАРАКТЕРИСТИКИ СЕТИ LTE 4.1. ОБЩИЕ ТРЕБОВАНИЯ К ОБОРУДОВАНИЮ СЕТИ LTE Сеть стандарта LTE планируется использовать для организации мобильного беспроводного широкополосного доступа абонентов в городах Алматы и Астана к сетям передачи данных и Интернет. Все технические параметры должны соответствовать международным стандартам и соответствующим нормативным документам Республики Казахстан, техническим требованиям к соединению с сетью передачи данных общего пользования и требованиям к качеству услуг. 4.1.1. Общие требования по совместимости оборудования 4.1.1.1. Поставщик должен предоставить информацию о результатах тестирования на совместимость IOT (Inter Operability Testing) поставляемого оборудования с оборудованием EPC, RAN с оборудованием других поставщиков. 4.1.2. Общие требования по надежности Поставляемое оборудование должно удовлетворять требованиям по надежности: 4.1.2.1. Коэффициент надежности/отказоустойчивости оборудования должен быть не менее 0,99999. 4.1.2.2. Программное обеспечение и все станционные данные должны храниться на жестких дисках, иметь возможность снятия резервных копий. 4.1.2.3. Должно быть обеспечено полное дублирование станционных данных. 4.1.2.4. Основные элементы уровня ядра сети должны быть зарезервированы по схеме 1+1 либо N+1. 4.1.2.5. Изменение конфигурации и любых настроек системы должно производиться без прерывания существующего трафика. 4.1.2.6. Должна быть реализована возможность возврата к предыдущей конфигурации программного обеспечения, таблиц маршрутизации и подсистемы повременного учета в случае неудачной попытки модификации, по команде оператора. 4.1.2.7. Резервирование всех плат элементов EPC, влияющих на прохождение трафика в каждом отдельно взятом устройстве. Переключение на резервную плату должно производиться без прерывания существующего трафика. 4.1.2.8. «Горячая» замена плат должна производиться без снятия питающего напряжения с шасси и без прерывания существующего сервиса. 4.1.2.9. Резервирование всех интерфейсных соединений элементов EPC. Переключение на резервный интерфейс должно производиться без прерывания существующего сервиса. 4.1.2.10. Возможность подключения к двум независимым источникам электропитания. Переключение на резервный источник питания должно производиться без прерывания существующего трафика. 4.1.2.11. Обновление, модификацию и перезагрузку программного обеспечения для каждого отдельно взятого устройства и для всей системы в целом, должно происходить без прерывания существующего трафика. 4.1.3. Общие требования по масштабируемости 4.1.3.1. Расширение системы должно производиться при помощи простого подключения дополнительных модулей для увеличения производительности только той функциональной части системы, которая подлежит расширению. 4.1.3.2. Модульная архитектура не должна накладывать ограничений на дальнейшее расширение оборудования в будущем. 4.1.4. Общие требования по совместному использованию сети (Network sharing) 34 4.1.4.1. Поставляемое оборудование должно поддерживать режим совместного использования сети (Network sharing) и соответствовать требованиям, описанным в документах 3GPP TR 22.951, TS 23.251. 4.2. ОБЩИЕ ТРЕБОВАНИЯК АРХИТЕКТУРЕ ПОСТРОЕНИЯ СЕТИ LTE 4.2.1. Предложения по архитектуре построения сети должны соответствовать требованиям 3GPP Rel.9 в части описания стандарта LTE (Long-Term Evolution) и состоять из следующих уровней: Сеть Транспорт Evolved Packet RAN Интернет Mobile BackHaul Core и ПД OSS Алматы OSS UDC Биллинговая система Internet Источник синхронизации РРЛтранспорт PCRF MME Mobile BackHaul E-UTRAN S-GW P-GW DPI NAT/ FW Источник синхронизации Астана РРЛ DWDM/ MPLS Mobile BackHaul Рис. 4.1 Архитектура сети LTE 4.2.2. Уровень ядра сети. Оборудование ядра сети, выполняющее функции: MME, UDC, SGW/PGW, DPI, PCRF, Биллинг и сервера приложений. Оборудование ядра сети планируется установить централизовано в Алматы. Назначение устанавливаемого оборудования: UDC (Used Data Convergence – сервер с информационной базой данных абонентов сети мобильной связи — управляет информацией, необходимой для установления подлинности абонентов, и информацией о посещении сети. MME – Mobility Management Entity – логический узел, реализующий управление и контроль мобильным доступом. S-GW/P-GW (S-GW – Serving Gateway, Обслуживающий Шлюз / P-GW – Packet Data Network Gateway, Пакетный шлюз). DPI - (Deep Packet Inspection, анализатор трафика); PCRF - (Policy and Charging Rules Function, сервер политик). OSS – (Operation Support System, система управления сетью), Биллинг – центр обработки биллинговых записей и выставления счетов абонентам, управление абонентами и услугами. Сервера приложений – организация различных дополнительных услуг. 4.2.3. Уровень транспорта. Уровень транспорта в структуре сети LTE базируется на пакетной коммутации. Для передачи трафика между городами планируется использовать междугороднюю сеть DWDM/MPLS. Внутри городов планируется строить мобильную транспортную сеть (MBH) с использованием темного оптического волокна сети FTTH. При отсутствии возможности организации оптической соединительной линии, для отдельных eNodeB будут организованы радиорелейные линии (РРЛ) 35 с установкой соответствующего оборудования. Транспортный уровень объединяет уровень доступа с уровнем ядра. Пропускная способность транспортной сети будет увеличиваться по мере увеличения трафика. 4.2.4. Уровень доступа. В структуре сети LTE уровень доступа строиться на основе RAN (сети радиодоступа) стандарта LTE, в частотных диапазонах, выделенных для построения сети. Для построения RAN планируется использовать мультистандартные и мультидиапазонные базовые станции (eNodeB). Планируется использовать базовые станции различной конфигурации и емкости. Для увеличения пропускной способности eNodeB будет использоваться технология MIMO 2х2. 4.2.5. Абонентский уровень. Клиентское оборудование (оконечные абонентские устройства) для абонентов сети LTE. 4.3. ОБЩИЕ ТРЕБОВАНИЯ К ИСПОЛЬЗУЕМЫМ ЧАСТОТНЫМ ДИАПАЗОНАМ 4.3.1.1. Для построения сети LTE планируется использовать диапазон частот - 3GPP Band 3: 1805-1880 МГц (в направлении «к абоненту»)/1710-1785 (в направлении «от абонента»), в режиме частотного разделения дуплексных каналов (FDD LTE). Номиналы частот 1765-1785/1860-1880МГц, ширина несущей – 20МГц. 4.3.1.2. Поставляемое оборудование должно иметь возможность модернизации для поддержки одновременной работы в диапазонах частот 1710-1785/1805-1880МГц, ширина несущей 5, 10, 15, 20МГц и 832-862/791-821МГц, ширина несущей от 5 МГц и выше. 4.4. ОБЩИЕ ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ СЕТИ LTE 4.4.1.1. Оборудование Сети LTE должно обеспечивать аутентификацию абонентов при пользовании всеми видами услуг (услуги передачи данных, дополнительные услуги) для исключения возможности несанкционированного доступа и клонирования. 4.5. ТРЕБОВАНИЯ К СИНХРОНИЗАЦИИ 4.5.1.1. Синхронизация сети LTE в городах Алматы и Астана должна осуществляться по протоколам: IEEE-1588v2 для RAN; NTPv4 для EPC. 4.5.1.2. Синхронизация осуществляется от источника, предоставляемого Заказчиком. 36 5. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К EPC 5.1. ОБЩИЕ ТРЕБОВАНИЯ К EPC Оборудование EPC (Evolved Packet Core) является ядром сети стандарта LTE. Для построения сети LTE один комплекс оборудования EPC планируется установить в г. Алматы с обслуживанием RAN в гг. Алматы и Астана. Все элементы EPC должны поставляться в стойках/шкафах одного типоразмера и внешнего дизайна. 5.1.1. Общие требования к составу EPC Оборудование EPC (Evolved Packet Core) должно соответствовать требованиям спецификаций 3GPP не ниже чем Rel.9 и состоять из следующих элементов: 5.1.1.1. MME(mobility management entity – узел управления мобильностью). 5.1.1.2. UDC (user data convergence – конвергентная база данных) 5.1.1.3. S-GW (serving gateway – обслуживающий шлюз). 5.1.1.4. P-GW (packet data network gateway – пакетный шлюз). 5.1.1.5. DPI (deep packet inspection – анализатор трафика). 5.1.1.6. PCRF (policy and charging rules function – узел управления политик). 5.1.1.7. OSS (operation support system – система управления сети). 5.1.1.8. Ethernet коммутаторы (IP коммутаторы). 5.1.1.9. FireWall (межсетевой экран). 5.1.1.10. Маршрутизаторы EPC. 5.1.1.11. Система гарантированного электропитания с аккумуляторными батареями, 5.1.1.12. Дизель-генератор. 5.1.2. Общие технические требования к EPC 5.1.2.1. EPC должен обеспечивать возможность реализации следующих услуг: 5.1.2.1.1. Доступ в сеть Интернет абонентов LTE; 5.1.2.1.2. Доступ в сеть Интернет со статическим и динамическим IP; 5.1.2.1.3. VPN (Р2Р/L2TP/IPSec); 5.1.2.1.4. Обеспечивать возможность побайтной и посекундной тарификации всех этих услуг (включая он-лайн тарификацию), с учетом информации о местоположении абонента (сектор eNodeB). 5.1.2.1.5. Обеспечивать возможность он-лайн тарификации не менее чем для 300 000 абонентов, с возможностью дальнейшего увеличения до 4 000 000 абонентов. 5.1.2.2. Для каждого элемента EPC поставщик должен предоставить информацию по производительности; предлагаемой и максимально возможной конфигурации (HW Capacity) и объему поставляемых лицензий; стоимость дальнейшего расширении емкости в 1.5, 2, 4 раз; стоимость послегарантийной поддержки и расчет TCO (полной стоимость владения) на 3 года. 5.1.2.3. Для всех элементов EPC должна существовать возможность замены любой платы или блока без остановки сервиса абонентам. 5.1.2.4. На всех элементах EPC достижение высокой загрузки не должно приводить к проблемам в управлении, потере аварийных сообщений или потере статистической информации. При таких случаях система должна выдавать предупреждения о таких ситуациях. 5.1.2.5. Все элементы EPC должны иметь физически раздельные интерфейсы для трафика абонентских данных и управления. 5.1.2.6. EPC должен обеспечивать работу абонентов в сетях других операторов (роуминг), и возможность работы абонентов других сетей в сети ЗАКАЗЧИКА. 5.1.2.7. EPC должен обеспечивать полную поддержку использования адресов только IPv4, только IPv6 и комбинированное использование IPv4/IPv6 на стороне абонентских терминалов и на транспортном уровне. 37 Поставщик обязан предоставить полный пакет документации на поставляемые элементы сети. Документация должна быть предоставлена не менее чем в пяти экземплярах на CD-дисках, на английском языке и включать в себя следующую информацию: 5.1.2.8.1. общее описание; 5.1.2.8.2. описание всех базовых и опциональных функций оборудования и программного обеспечения; 5.1.2.8.3. описание всех аварийных и информационных сообщений генерируемых оборудованием и инструкции по действию персонала при их возникновении; 5.1.2.8.4. описание всех конфигурационных параметрах доступных оператору и способы их изменения; 5.1.2.8.5. описание статистических параметров для отслеживания нормального функционирования и рекомендации по уровням загрузки отдельных подсистем; 5.1.2.8.6. рекомендации по отслеживанию качественных параметров работы оборудования; 5.1.2.8.7. рекомендации по профилактическому обслуживанию оборудования; 5.1.2.8.8. инструкции по замене плат и отдельных узлов оборудования. 5.1.2.9. Поставщик обязан дать рекомендации по количеству персонала оператора необходимого для полноценного обслуживания оборудования. 5.1.2.10. EPC должна иметь возможность одновременной поддержки работы радиосетей LTE, GSM/HSPA и WiFi. Отдельным документом поставщик предоставляет список и стоимость оборудования и ПО, необходимых для поддержания данной возможности для поставляемого оборудования. 5.1.2.11. EPC должна поддерживать режимы переключения абонента при использовании услуги передачи данных между радиосетями GSM/HSPA/LTE без разрыва соединения, с использованием протоколов S3 и S4 в соответствии с требованиями 3GPP, а также с сетями не 3GPP: WiFi и другие. 5.1.2.12. Все элементы EPC должны обеспечивать работоспособность при выходе из строя любого отдельного блока или платы. Поставщик обязан предоставить описание принципов резервирования каждого элемента сети и ядра EPC в комплексе. 5.1.2.13. Все элементы EPC должны обеспечивать возможность электропитания от двух независимых систем электроснабжения. И в случае выхода одной из них должна обеспечиваться полноценная работоспособность EPC. 5.1.2.14. Поставщик обязан предоставить план дальнейшего развития всех элементов EPC (road map) и гарантировать их полноценную поддержку в течении не менее 5 лет. 5.1.2.15. Все элементы EPC должны обеспечивать возможность создания резервных копий конфигурации и абонентских данных на внешних носителях без прерывания сервиса, а также возможность восстановления этих данных на оборудовании с резервных копий. 5.1.2.16. Поставщик должен предоставить описание всех внешних интерфейсов, используемых при управлении абонентами и услугами, форматы файлов CDR/PDR, протоколов онлайн тарификации для интеграции с биллинговой системой Заказчика. В случае использовании стандартных протоколов предоставляется документ о версиях протоколов с которым обеспечивается полная совместимость и детальная информации об отклонениях от стандарта. 5.1.2.17. Поставщик должен предоставить информацию о своем участии в работе над стандартами 3GPP, включая информацию о возможности инициировать внесение изменений в эти стандарты. 5.1.2.18. Все элементы EPC должны поддерживать использование протокола NTPv4 для синхронизации времени. Изменение настроек параметров синхронизации должно быть доступно на операторском уровне. 5.1.2.8. 5.1.3. Технические требования по интеграции с биллинговой системой 38 5.1.3.1. Записи CDR предлагаемой платформы (P-CDR и S-CDR) должны полностью соответствовать 3GPP TS 32.298. Кроме того, записи должны содержать следующие поля, относящиеся к абонентской протокольной сессии (как минимум): 5.1.3.1.1. Тип используемого в сессии протокола (например, HTTP, SMTP, SIP, RTP и т.д.) 5.1.3.1.2. Направление передачи (к или от абонента) 5.1.3.1.3. Продолжительность сессии 5.1.3.1.4. Отметка времени первого пакета сессии 5.1.3.1.5. Отметка времени последнего пакета сессии 5.1.3.1.6. Номер порта TCP/UDP сервера 5.1.3.1.7. Номер порта TCP/UDP приложения на абонентском устройстве 5.1.3.1.8. IP-адрес источника 5.1.3.1.9. IP-адрес назначения 5.1.3.1.10. Объем данных, переданных в рамках данной протокольной сессии, в каждом направлении. 5.1.3.2. Биллинг postpaid абонентов. - Должны формироваться записи CDR для каждой успешной или неуспешной транзакции. Должна обеспечиваться возможность передачи CDR файлов на CDR сервер оператора по протоколу FTP. 5.1.3.3. Записи CDR предлагаемой платформы должны содержать, по крайней мере, следующие поля: 5.1.3.3.1. идентификатор транзакции (Transaction-ID); 5.1.3.3.2. идентификатор сессии (Session-ID); 5.1.3.3.3. время начала сессии (Session start time); 5.1.3.3.4. время начала транзакции (Transaction start-time); 5.1.3.3.5. время окончания транзакции (Transaction end-time); 5.1.3.3.6. IP-адрес источника (Source-IP); 5.1.3.3.7. первоначальный IP-адрес назначения (Destination original IP); 5.1.3.3.8. первоначальный порт назначения (Destination original port); 5.1.3.3.9. MIN/MSISDN; 5.1.3.3.10. MDN (если имеется); 5.1.3.3.11. тарифный план (Data plan); 5.1.3.3.12. URL; 5.1.3.3.13. код состояния (Status code); 5.1.3.3.14. тип абонента (prepaid/postpaid); 5.1.3.3.15. идентификатор базовой станции; 5.1.3.3.16. объем трафика исходящий; 5.1.3.3.17. объем трафика входящий; 5.1.3.3.18. использованный протокол. 5.1.3.4. Должна быть предусмотрена возможность выгрузки CDR во внешние базы данных Заказчика(3GPP TS 32.297). 5.1.3.5. С целью организации биллинговых процессов в реальном времени, Поставщик должен обеспечить возможность интеграции EPC с prepaid-платформой оператора посредством протокола DIAMETER (3GPP TS 32.299). 5.1.3.6. Должна быть реализована возможность тарификации и контроля предоставления услуги prepaid-абонентам по объему использованных услуг, по продолжительности сессии, по событиям, по местоположению абонента и по сочетанию этих критериев. 5.1.3.7. Должны присутствовать возможности по ограничению времени действия квоты, фиксации событий смены тарифных планов. 5.1.3.8. Должна поддерживаться контентная тарификация на базе любых из следующих компонентов: протокол, группа URL/URL, атрибуты RADIUS, тип MIME, IP-адреса источника и назначения. 5.1.3.9. Должна быть предусмотрена возможность выделения prepaid платформой общей квоты для группы сервисов, с использованием протокола DIAMETR. 39 5.1.3.10. Должна быть предусмотрена возможность различной тарификации prepaid-абонентов на базе используемых ими протоколов. Например: абонент будет оплачивать различные суммы при использовании протоколов P2P, HTTP, RTSP и VOIP 5.1.3.11. Должна быть предусмотрена возможность различной тарификации prepaid-абонентов на базе используемых ими протоколов и дополнительных параметров, например, типа устройства, абонентской информации и атрибутов RADIUS. 5.1.3.12. Должна быть предоставлена возможность проверки абонентского баланса и расчета резервируемых значений на основании применяемых методов тарификации в рамках политики prepaid-тарификации. 5.1.3.13. Должна быть обеспечена возможность блокировать действия абонента при достижении им нулевого баланса, абонент должен направляться на Портал Оператора. 5.1.3.14. Должна быть предоставлена возможность работать с не тарифицируемым трафиком. Не тарифицируемый трафик позволит абонентам пользоваться внутренним порталом оператора даже по достижении им нулевого баланса. 5.1.3.15. Должно обеспечиваться гарантированное обслуживание prepaid-абонентов в случае недоступности биллинговой системы реального времени ЗАКАЗЧИКА. Объемы гарантированного обслуживания задаются администратором. 5.1.3.16. Должен обеспечиваться механизм работы с несколькими DIAMETER серверами и возможность переключения между ними в случае срабатывания правил по недоступности, нагрузке и т.д. 5.1.3.17. Так же для prepaid абонентов должны формировать записи CDR для каждой успешной или неуспешной транзакции. 5.1.3.18. Требуется наличие API к базе данных абонентских профилей (UDR) для управления данными абонента биллинговой системой. 5.2. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ММЕ 5.2.1. Общие технические требования к ММЕ 5.2.1.1. Поставщик должен предложить решение MME, соответствующее требованиям к MME, определенным в релизе 3GPP Rel.9. 5.2.1.2. ММЕ должна поддерживать вывод аварийных сигналов, добавление всех аварийных уведомлений в историю (аларм лист), фильтрацию сигналов по приоритетности. 5.2.1.3. Должна быть обеспечена возможность предоставления отчетов в режиме реального времени относительно использования услуг конечными пользователями. 5.2.1.4. Должна быть обеспечена возможность предоставления отчетов об ошибках, в случаях неудачных попыток использования сервисов. 5.2.1.5. MME должна обеспечивать поддержку протокола S11 согласно TS 29.274 5.2.1.6. MME должна обеспечивать поддержку протокола S6a согласно TS 29.272 5.2.1.7. ММЕ должна обеспечивать поддержку протокола S1-MME согласно TS 24.301 5.2.1.8. MМE должна обеспечить проверку EPS-AKA при авторизации пользователя. 5.2.1.9. MME должен иметь возможность выбора S-GW/ P-GW в зависимости от текущей загрузки. 5.2.1.10. Обеспечивать передачу и обработку информации об изменении параметров профайла абонента, получаемых с UDC. 5.2.1.11. MME должна поддерживать функциональность SON, авто-конфигурирование интерфейса S1 и настройку списка соседей для eNodeB. 5.2.1.12. Поставщик должен описать предлагаемое оборудование с точки зрения характеристик аппаратного и программного обеспечения (внутренняя аппаратная архитектура, типа различных плат, масштабируемость, возможные конфигурации, программная архитектура, операционная система, структура БД, если используется, и т.д.). 5.2.1.13. Поставщик должен предоставить подробное техническое описание предлагаемого решения MME, в том числе предоставить: 5.2.1.13.1. архитектуру решения; 40 5.2.1.13.2. высокоуровневое описание решения; 5.2.1.13.3. подробные технические описания каждого компонента платформы. 5.2.2. Требования к производительности MME. 5.2.2.1. MME должен обеспечивать возможность подключения не менее 351 eNodeB. 5.2.2.2. MME должен иметь возможность масштабирования для поддержки до 8 тыс. eNodeB и до 4 млн. абонентов. 5.2.2.3. Решение MME должно поддерживать не менее 60 000 PDP и иметь возможность расширения до 500 000 PDP. 5.2.2.4. Поставщик должен описать возможности своего решения с точки зрения: 5.2.2.4.1. Количества одновременно подключенных абонентов, отдельно для Idle и Connected абонентов; 5.2.2.4.2. Количества одновременно установленных PDP-контекстов/несущих; 5.2.2.4.3. Производительности: максимальное количество запросов Attach в секунду, максимальное количество Inter/Intra SGSN RAU, максимальное количество Intra MME TAU в секунду, максимальное количество обновлений PDPконтекстов/несущих в секунду и т. д.; 5.2.2.4.4. Максимального количество подключенных eNodeB и шлюзов; 5.2.2.4.5. Пропускной способность в Гбит/с для 4G. 5.2.2.5. Поставщик должен описать, как емкость платформы зависит от сочетания абонентов, использующих различные технологии радиодоступа. 5.2.2.5.1. Поставщику предлагается указать производительность MME на стандартную стойку 19‘ (при 70% загрузке CPU) в виде количества абонентов (SAU), одновременно активных PDP-контекстов, количества транзакций в секунду и других соответствующих параметров. Необходимо указать, существуют ли какие-либо ограничения на данные величины, зависят ли они друг от друга, от профиля абонентского трафика и т.д. 5.2.2.5.2. Поставщик должен указать влияние использования различных технологий доступа на производительность MME с точки зрения конфигурации, загрузки CPU, ёмкости, сигнализации, состава платформы и т.д. 5.2.2.5.3. Поставщик должен указать количество SAU, PDP, физических и логических сетевых соединений для минимальной конфигурации и для дальнейшего пошагового расширения вплоть до максимальной конфигурации. 5.2.2.5.4. Поставщик должен указать максимальное количество eNodeB, поддерживаемых MME. 5.2.2.5.5. Поставщик должен указать количество и масштабируемость интерфейсов, поддерживаемых на MME. 5.2.2.5.6. Поставщик должен представить описание и результаты нагрузочных тестов сетевых элементов, если таковые проводились. 5.2.2.6. Поставщик должен описать влияние изменения профиля трафика на производительность платформы. 5.2.2.7. Поставщик должен описать принципы планирования конфигурации платформы в зависимости от требуемой емкости, с приведением принципов расчетов конфигурации. 5.2.2.8. Поставщик должен быть готов продемонстрировать результаты в лаборатории поставщика и/или на этапе пилотного запуска. 5.2.3. Требования по поддержке интерфейсов 5.2.3.1. Платформа MME должна поддерживать следующие интерфейсы, в соответствии с IEEE 802.3: 5.2.3.1.1. 100MBASE-T (опционально); 5.2.3.1.2. Оптические интерфейсы 1/10GBASE; 5.2.3.1.3. Медные 1GBASE-T; 41 5.2.3.2. 5.2.3.3. 5.2.3.4. 5.2.3.5. 5.2.3.6. Поставщик должен указать для каждого логического интерфейса соответствующий физический интерфейс, скорость и протокол. Поставщик должен представить информацию о любых других реализованных интерфейсах, не указанных в документах 3GPP. Поставщик должен предоставить информацию о типе и физических параметрах всех поддерживаемых интерфейсов, например: тип среды, тип разъемов, поддерживаемые режимы и пропускная способность, используемые стандарты. Поставщик должен указать число логических связей/соединений, поддерживаемых на одном интерфейсе и в целом, рекомендуемую /максимальную загрузку каждого отдельного интерфейса модуля платформы, рекомендуемую/максимальную загрузку отдельных модулей. Поставщик должен указать существующие ограничения для предлагаемых интерфейсов в случае если их пропускная способность отличается от физической. 5.2.4. Требования к эксплуатации и техническому обслуживанию 5.2.4.1. Решение должно включать в себя подсистему для эксплуатации и технического обслуживания (O&M) платформы интегрированной в OSS. 5.2.4.2. Поставщик должен предоставить подробное описание O&M подсистемы и ее функциональных возможностей. 5.2.4.3. Любая операция, которая может быть выполнена непосредственно на платформе MME, должна быть также доступна через приложение с дружественным интерфейсом из подсистемы O&M интегрированной в OSS. 5.2.4.4. Предлагаемая подсистема O&M должна обеспечивать устойчивое функционирование и обслуживание системы независимо от загрузки платформы MME и быть интегрированной в OSS. 5.2.4.5. Предлагаемая подсистема O&M должна обеспечивать интерфейс для обслуживания всех элементов решения, в том числе должна предоставлять возможность наблюдения за трафиком, назначения аварийных порогов, обнаружения и изоляции аварий, а также восстановления после сбоев. Физические и программные интерфейсы между элементами решения и подсистемой O&M должны быть совместимы с открытыми стандартами и спецификациями. 5.2.4.6. Должна быть предусмотрена возможность сбора статистической информации, связанной с любым значимым событием на оборудовании сети. Функциональность сбора статистики должна быть настраиваемой, например, должна быть предусмотрена возможность включения и отключения счетчиков, установки интервала измерений и автоматического создания статистических отчетов. Также должно быть реализована возможность автоматического удаления статистических данных. 5.2.4.7. Поставщик должен предоставить подробный список KPI для решения MME, который может быть использован для контроля правильной работы и производительности решения MME. Каждый KPI должен иметь подробное описание. 5.2.4.8. Поставщик должен предоставить матрицу совместимости между версиями подсистемы O&M (SW и HW) и версиями платформы MME. 5.2.4.9. Поставщик должен предоставить подробные сведения о выборе конфигурации (dimensioning) для подсистемы O&M, в том числе подробное описание зависимостей для конфигурации подсистемы O&M. Зависимости должны включать в себя, как минимум: 5.2.4.9.1. Количество подключаемых/обслуживаемых платформ MME; 5.2.4.9.2. Используемая аппаратная платформа и конфигурация; 5.2.4.9.3. Максимальное число одновременных пользовательских сессий и т.д. 5.2.4.10. Поставщик должен описать интерфейсы и протоколы платформы MME, которые могут быть использованы для подключения к внешним O&M решениям (для загрузки оповещений и статистики). 5.2.4.11. Подсистема O&M должна поддерживать следующие типы интерфейсов (NBI, NorthBoundInterface) для передачи сообщений в систему OSS: 42 5.2.4.11.1. SNMP (Simple Network Monitoring Protocol) Trap (RFC 1215) и SNMP Table (SNMPGet, RFC1157) 5.2.4.11.2. ASCII по TCP (Transmission Control Protocol) 5.2.4.11.3. CORBA 5.2.4.11.4. Q.3 (ITU-T Q.811 Q.812 Q.821 Q.822) 5.2.4.11.5. SQL 5.2.4.11.6. SQL через ODBC (Open Database Connectivity) / JDBC (Java Database Connectivity) 5.2.4.11.7. STDIN (стандартный ввод) / STDOUT (стандартный вывод) с использованием удаленного доступа (SSH, Telnet) 5.2.4.12. Платформа MME должны иметь возможность настройки в интерактивном режиме из OSS или с терминала с помощью: 5.2.4.12.1. SSH 5.2.4.12.2. TELNET 5.2.4.12.3. веб-браузер и/или дополнительного GUI-приложения ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К UDC 5.3. Общие технические требования к UDC Поставщик должен предложить решение UDC (конвергентную базу данных). Предлагаемое решение должно обеспечивать хранение и управление данными абонентов в сети LTE в соответствии с правилами и политикой тарификации (PCRF). 5.3.1.3. Оборудование UDC должно соответствовать трем основным требованиям: 5.3.1.3.1. иметь многоуровневую архитектуру состоящую из уровня базы данных (UDR), уровня приложений (HSS, AuC, AAA, SPR) и трафика; 5.3.1.3.2. должно иметь возможность расширения и одновременной поддержки сетей LTE и 2G/3G; 5.3.1.3.3. должно иметь возможность организации географического резервирования с установкой резервного узла в другом регионе Казахстана. 5.3.1.4. Для соблюдения этих требований UDC должна соответствовать спецификациям по конвергенции пользовательских данных 3GPP (UDC) 3GPP TR 22.985. 5.3.1. 5.3.1.1. 5.3.1.2. 5.3.2. Общие требования к архитектуре UDC 5.3.2.1. 5.3.2.2. 5.3.2.2.1. 5.3.2.2.2. 5.3.2.2.3. 5.3.2.2.4. 5.3.2.3. 5.3.2.4. 5.3.2.5. 5.3.2.6. UDR должно осуществлять синхронную поддержку абонентских данных в нескольких приложениях. UDR должно быть открыто для поддержки в будущем других приложений для хранения и управления данными по подписке пользователей, включая: HLR – Реестр абонентов для сетей 2G и 3G, MNP – Приложение «возможность переноса мобильного номера», EIR – Приложение «Реестр идентичности оборудования», Прочие приложения. Приложения, связанные с UDR, должны иметь унифицированную модель базы данных для данных по подписке пользователей. UDR должно позволять осуществить расширение унифицированной модели базы данных по подписке пользователей в случае подсоединения нового приложения к UDR. Приложения должны иметь возможность извлекать данные из UDR и хранить данные в нем. Приложения отвечают за обновление UDR с динамическими изменениями профиля пользователя исходя из трафика (например, статус пользователя, место нахождения пользователя) или как последствие процедур абонента. На уровне приложений должны находятся различные приложения (например, HSS, SPR, HLR), каждое из которых должно поддерживать различные протоколы доступа (например, Diameter, LDAP, MAP), требуемые для специальных приложений. 43 Уровень приложений также должен обеспечивать стандартный двунаправленный интерфейс для системы provisioning. Этот интерфейс должен использоваться системой provisioning для управления данных пользователя различных приложений записанных в UDR - центральной базе данных. 5.3.2.8. На уровне баз данных должны находиться все данные для всех приложений. 5.3.2.9. Уровень разделения должен находиться между уровнем приложений и уровнем баз данных и выполняет следующие основные функции: 5.3.2.9.1. Доступ к средствам управления всеми приложениями и их привязками к данным, сохраняемым в базе данных; 5.3.2.9.2. Данные по маршрутам, т.е. находит физическое место в базе данных, где хранится запрашиваемая информация; 5.3.2.9.3. Управляет правами по назначению приоритетов и прав доступа приложений для доступа к данным в базе данных. 5.3.2.10. Поставщик должен предоставить общую блок-схему и функциональную схему системы. 5.3.2.11. Поставщик должен указать принципы резервирования, применяемые для резервирования определенного блока, например, «горячее резервирование», «холодное резервирование», N+1, 2N. Описать воздействие переключения блока на функционирование системы. Поставщик должен указать, требуется ли перезапуск для активации резервного блока. Также необходимо указать, возникает ли перерыв в обслуживании вследствие перезапуска системы. 5.3.2.12. Все наиболее важные компоненты для регулирования трафика и тарификации должны дублироваться механизмом автоматического переключения во избежание нарушение трафика или потери информации по тарификации. 5.3.2.13. Поставщик должен предоставить общее описание архитектуры программного обеспечения продукта для каждого компонента 5.3.2.14. Поставщик должен указать имеющийся протокол интерфейса между фронтальными приложениями и базой данных. 5.3.2.15. Решение Поставщика должно предусматривать соответствующие данные аутентификации, необходимые для аутентификации и кодирования для GSM, GPRS, EDGE, UMTS, LTE, HSDPA и HSUPA. 5.3.2.16. Поставщик должен указать, где и в каком формате хранятся Данные аутентификации – в закодированной или простой форме, а также как происходит защита транспорта информации AuC по всем интерфейсам, через которые данная информация передается. 5.3.2.17. Поставщик должен предоставить детальную документацию по архитектуре всего предлагаемого оборудования. 5.3.2.18. UDC должны поддерживать возможность выгрузки из БД всех абонентских данных (идентификаторы абонентов, идентификаторы всех услуг и персональные настройки) в текстовом виде или в формате, совместимом с внешними БД для проведения сверок с биллинговой системой ЗАКАЗЧИКА. 5.3.2.19. В состав UDC должны входить следующие компоненты: 5.3.2.19.1. HSS(AuC) 5.3.2.19.2. SPR 5.3.2.19.3. AAA 5.3.2.7. 5.3.3. Технические требования к системе хранения данных пользователя (UDR) 5.3.3.1. 5.3.3.2. 5.3.3.3. Поставщик должен указать, какой стандарт базы данных выбран для UDR. Поставщик должен перечислить функциональные компоненты базы данных и дать краткое разъяснение по каждому компоненту. Поставщик должен указать механизмы резервирования и сохранения (B&R), имеющиеся в базе данных. 44 5.3.3.4. 5.3.3.5. 5.3.3.6. 5.3.3.7. 5.3.3.8. 5.3.3.8.1. 5.3.3.8.2. 5.3.3.8.3. 5.3.3.8.4. 5.3.3.8.5. 5.3.3.8.6. 5.3.3.8.7. Поставщик должен описать механизмы базы данных, применяемые для выполнения непрерывного резервного копирования базы данных внутренней памяти в режиме реального времени Поставщик должен разъяснить, как система позволяет выполнять выгрузку части содержимого базы данных, используя различные типы критериев. Выходные данные должны быть в читаемом и практически применимом формате, для генерирования серии команд (с использованием скриптов для обновления). Модель данных (абонентов) должна иметь возможность расширения для того, чтобы она могла использоваться другими приложениями. Поставщик должен объяснить, как выполняется расширение модели данных. Поставщик должен предоставить детальную информацию об интерфейсах базы данных. Централизованная база данных абонентов должна обеспечивать: Высокую степень доступности Надежность Способность к восстановлению Высокий уровень масштабируемости и возможности расширения Гибкость Быструю обработку информации Поставщик должен обеспечить быстрый доступ к базе данных. 5.3.4. Технические требования к HSS 5.3.4.1. 5.3.4.2. 5.3.4.3. 5.3.4.4. 5.3.4.5. 5.3.4.6. 5.3.4.7. Поставщик должен дать информацию касательно доступности и внедрения программного обеспечения HSS. Поставщик должен разъяснить, как приложение HSS будет интегрировано в UDC. Необходимо описать интерфейсы и протоколы интеграции. Приложение HSS и Центра аутентификации (AuC) Поставщика должно соответствовать требованиям спецификации 3GPP. Поставщик предоставит краткое описание своего оборудования HSS и AuC. HSS должен обеспечивать поддержку протокола S6a согласно TS 29.272. Поставщик должен разъяснить, какие стандартные алгоритмы аутентификации поддерживаются в HSS. Поставщик должен указать пропускную способность HSS и все виды интерфейсов. HSS должен обеспечивать проверку подлинности абонентов с использованием алгоритма EPS-AKA. 5.3.5. Аспекты контроля резервирования, масштабируемости и нагрузки 5.3.5.1. 5.3.5.2. 5.3.5.3. 5.3.5.4. 5.3.5.5. 5.3.5.6. Система должна быть разработана без критических точек касательно аппаратного обеспечения, программного обеспечения, модулей и интерфейсов. Во избежание единой точки отказа, UDC должно поддерживать распределение и резервирование данных абонентов через географически распределенные копии данных абонентов. Поставщик должен разъяснить концепцию внутреннего резервирования, поддерживаемую решением, в отношении электропитания, процессора, интерфейса и других компонентов аппаратного обеспечения. Поставщик должен описать все методы, обеспечивающие высокую степень доступности системы. Надежность всей системы должна быть равна или превышать 99.999%, и суммарное время простоя системы должно составлять менее 5 минут в год. Поставщик должен указать максимальную производительность всей системы и должен обеспечить, чтобы наращивание пропускной способности системы не вызвало ее сбой. 45 5.3.5.7. 5.3.5.8. 5.3.5.9. Должны быть реализованы механизмы контроля нагрузки и защиты от перегрузки. UDC должно обеспечивать независимую масштабируемость уровня сетевого трафика и хранения данных. Поставщик должен описать политики обеспечения безопасности, разработанные в оборудовании, также как и все предлагаемую систему. Политики могут включать в себя идентификацию по имени пользователя /паролю, системную и операционную регистрацию, пользовательское управление по пользовательским профилям (классы пользователей), предлагая различные наборы операционных/управленческих функций (например: обеспечение, предоставление отчетов, управление конфигурацией, и т.п.), с регистрацией их действий. 5.3.6. Требования к архиву данных по профилям абонентов SPR (Subscriber Profile Repository) Поставщик должен дать информацию касательно доступности и внедрения программного обеспечения архива данных по профилям абонентов (SPR). 5.3.6.2. Поставщик должен дать разъяснения касательно того, как PCRF может получить доступ к SPR в режиме реального времени. 5.3.6.3. Поставщик должен разъяснить, как PCRF может быть интегрирована с SPR. Необходимо описать интерфейсы и протоколы интеграции. 5.3.6.4. Поставщик должен разъяснить, какие коды может использовать PCRF для доступа в SPR. 5.3.6.5. SPR должен поддерживать протокол Sp согласно 3GPP TS 23.203, TS 29.328 5.3.6.1. 5.3.7. Provisioning System 5.3.7.1. 5.3.7.2. 5.3.7.3. Поставщик должен дать разъяснения по архитектуре provisioning system Поставщик должен разъяснить, как система дает возможность выполнения Массового обновления для пользовательских профилей. Поставщик должен указать, какой тип данных можно обновить путем пакетной обработки. Должна быть предусмотрена возможность создания шаблонов для администрирования абонентов сети мобильной связи. 5.3.8. Поддерживаемые стандарты Предлагаемое решение должно соответствовать спецификациям 3GPP не ниже Rel.9. Поставщик должен заявить о соответствии всем применимым стандартам 3GPP. Поставщик должен заявить о соответствии всем применимым стандартам ETSI. Поставщик должен заявить о соответствии стандартам IETF. Поставщик должен заявить о соответствии стандартам ITU-T. Поставщик должен предоставить спецификации на все аппаратное обеспечение для решения UDC. 5.3.8.7. Поставщик должен описать аппаратную платформу, применяемую для Уровня баз данных UDR. 5.3.8.8. Поставщик должен описать аппаратную платформу, применяемую для системы HSS. 5.3.8.9. Поставщик должен описать аппаратную платформу, применяемую для системы HLR в случае, если приложение HLR будет применяться в будущем. 5.3.8.10. Аппаратное обеспечение должно отвечать требованиям промышленных стандартов в отношении высокого уровня готовности, устойчивости к отказам и масштабируемости. 5.3.8.11. Поставщик должен предоставить информацию по надежности предлагаемых системных элементов (MTBF), и он должен описать воздействие частичного или полного отказа аппаратного обеспечения и процедуру восстановления возможного отказа. Также необходимо указать среднее время восстановления (MTTR). 5.3.8.1. 5.3.8.2. 5.3.8.3. 5.3.8.4. 5.3.8.5. 5.3.8.6. 46 5.3.8.12. Для каждого узла необходимо предоставить детальную техническую спецификацию HW, включая: количество шкафов/квадратных метров, расход энергии и площадь основания, необходимые для узла с максимальными габаритами. 5.3.9. Показатели производительности системы и качества 5.3.9.1. 5.3.9.2. 5.3.9.3. Поставщик должен предоставить перечень Основных производственных показателей (KPI) системы. Необходимо предусмотреть функциональные возможности для активации аварийных сигналов при мониторинге пороговых значений счетчиков и KPI. Поставщик должен предусмотреть функциональные возможности QoS для того, чтобы оператор мог получить комплексный мониторинг качества. 5.3.10. Сетевые интерфейсы и протоколы 5.3.10.1. Поставщик должен указать, какие физические интерфейсы поддерживаются (например, Fast Ethernet, Gigabit и т.п.). 5.3.10.2. Поставщик должен указать, какие транспортные протоколы поддерживаются в физическом интерфейсе (например, MTP, SCTP и т.п.). 5.3.10.3. Поставщик должен указать, какие протоколы прикладных программ поддерживаются (например, Diameter, LDAP, SPML и т.п.). 5.3.10.4. Поставщик должен указать, какие требования по транспортной сети должны выполняться между уровнями (например, Gigabit Ethernet WAN и т.п.). 5.3.10.5. Поставщик должен описать механизмы распределения трафика из базовой сети в HSS для защиты системы от перегрузок. 5.3.10.6. Поставщик должен указать, какие протоколы поддерживаются между OSS и HSS (например, SNMP V3 и т.п.). 5.3.10.7. Поставщик должен указать все протоколы между базой данными и прочими компонентами в форме диаграммы. Поставщик должен описать протоколы связи, используемые для доступа к сетевым элементам для каждого компонента. 5.3.10.8. Система должна поддерживать динамические транзакции (только чтение, только запись смешанные операции и т.п.) из Приложений/Клиентов. 5.3.10.9. Любые изменения конфигурации в одном из соединений Приложение/Клиент не должны требовать перезапуска всех Приложений/Клиентов. 5.3.10.10. Любые изменения в определенном соединении Приложение/Клиент не должны требовать перезапуска этого Приложения/Клиента. Если требуется перезапуск, опишите ожидаемое время вынужденного простоя, и как данный вопрос решается в системе. 5.3.10.11. Система должна предусматривать административные инструменты для облегчения повторяющихся заданий в конфигурации или изменения в базе данных. 5.3.10.12. Система должна предусматривать интерактивную командную строку и графический пользовательский интерфейс для заданий администрирования. 5.3.11. Требования к производительности. 5.3.11.1. Платформа UDR должна быть рассчитана на хранение данных 300 000 активных абонентов и иметь возможность расширения до 4 000 000 абонентов. 5.3.11.2. Платформа UDC должна обеспечивать производительность интерфейса управления абонентами со стороны биллинговой системы не менее 2000 TPS. 47 5.4. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К S-GW/P-GW 5.4.1. Общие технические требования к S-GW/P-GW Комплекс оборудования S-GW/P-GW должен обеспечивать: 5.4.1.1. P-GW должен поддерживать Policy base routing (маршрутизация по правилам). Поставщик должен обозначить правила, которые могут использоваться для пересылки мобильному терминалу трафика в дополнение к обычному IP-routing на основе IPадреса назначения. 5.4.1.2. P-GW должен поддерживать основные протоколы туннелирования (IPSec, L2TP, GRE, IP-in-IP). 5.4.1.3. P-GW должен поддерживать опцию фильтрации пакетов для защиты P-GW против вторжения или для отражения сетевых атак. 5.4.1.4. Должна быть обеспечена возможность настройки P-GW для работы в качестве DHCPv6 клиента к внешним пакетным сетям для распределения IPv6 префиксов. 5.4.1.5. P-GW должен поддерживать внутренний DHCP сервер. 5.4.1.6. Поставщик должен описать возможные сигнальные процессы на P-GW для случаев использования интерфейса DIAMETER. 5.4.1.7. S-GW должен обеспечивать поддержку протокола S1-U согласно TS 29.274 5.4.1.8. S-GW должен обеспечивать поддержку протокола S11 согласно TS 29.274. 5.4.1.9. P-GW должен обеспечивать поддержку протокола Gx согласно TS 29.212. 5.4.1.10. P-GW должен обеспечивать поддержку протокола Gy согласно TS 32.251. 5.4.1.11. P-GW должен обеспечивать поддержку протокола SGi согласно TS 29.061. 5.4.1.12. P-GW должен обеспечивать поддержку протокола Gz согласно TS 32.240, TS 32.295. 5.4.2. Требования к производительности. 5.4.2.1. Платформа S-GW/P-GW должна иметь возможность обеспечить обслуживание 300 тыс. пользователей с общей пропускной способностью до 45 Гбит/с при максимальной нагрузке абонентскими сессиями и включенными политиками. 5.4.2.2. В дальнейшем S-GW/P-GW должны обеспечить возможность масштабирования до 1 000 000 пользователей с общей пропускной способностью 100 Гбит/с. 5.4.2.3. Поставщик должен предоставить данные по масштабируемости S-GW/P-GW по следующим критериям: 5.4.2.3.1. Максимальная производительность (Гбит/с) на SGi интерфейсе. 5.4.2.3.2. Максимальная производительность (Гбит/с) на SGi интерфейсе при задействовании глубокого анализа пакетов для 100% трафика на 7 уровне модели OSI. 5.4.2.3.3. Максимальное количество активных в момент времени PDP контекстов/несущих. 5.4.2.3.4. Максимальное количество активаций PDP контекстов/несущих в секунду. 5.4.2.3.5. Максимальное количество деактиваций PDP контекстов/несущих в секунду. 5.4.2.3.6. Максимальное количество обновлений PDP контекстов/несущих в секунду. 5.4.2.3.7. Максимальное количество Gx транзакций в секунду. 5.4.2.3.8. Максимальное количество Gy транзакций в секунду. 5.4.2.3.9. Максимальное количество хранимых CDR. 5.4.2.3.10. Максимальное количество конфигурируемых APN (Access Point Name). 5.4.2.3.11. Характеристики интерфейсов. 5.4.2.4. Поставщик должен описать модульность шасси S-GW/P-GW (возможности наращивания процессорной мощности, памяти, интерфейсов). 5.4.2.5. Поставщик должен описать возможности масштабирования по количеству IPинтерфейсов, поддерживаемых на S-GW/P-GW. 5.4.2.6. Поставщик должен сообщить о параметрах, негативно влияющих на производительность контрольной плоскости S-GW/P-GW. 5.4.2.7. Поставщик должен предоставить результаты нагрузочного тестирования S-GW/P-GW, если такой материал имеется. 48 5.4.2.8. 5.4.2.9. 5.4.2.9.1. 5.4.2.9.2. 5.4.2.9.3. 5.4.2.9.4. 5.4.2.9.5. 5.4.2.9.6. Поставщик должен описать влияние размера пакетов на производительность S-GW/PGW. Поставщик должен предоставить информацию о поддержке следующих протоколов: динамической маршрутизации (IGP, BGP); статической маршрутизации; VPN-маршрутизации; MPLS VPN (PE), VRF, VRF-Lite; 6PE/6VPE. LAG, VRRP. DiffServ 5.4.3. Функциональные требования 5.4.3.1. Предлагаемая платформа S-GW/P-GW должна включать в себя следующую функциональность: 5.4.3.1.1. Базовые функциональности S-GW, P-GW (поддержание несущих, управление сессиями, IP-маршрутизация и т.д.). 5.4.3.1.2. Онлайн-тарификация, основанная на DCCA посредством Gy интерфейса. 5.4.3.1.3. Управление политиками, основанное на протоколе DIAMETER посредством Gx интерфейса. 5.4.3.1.4. Функциональность глубокого анализа пакетов, используемая для ограничения логических сессий по типам сервиса/приложениям (HTTP/WAP/MMSVoIP и т.д.), и используемая вместе с тарификацией и PCC. 5.4.3.1.5. Офлайн-тарификация. 5.4.4. Описание интерфейсов и их характеристик 5.4.4.1. Поставщик должен предоставить информацию о типах и физических параметрах всех поддерживаемых интерфейсов (тип среды передачи, разъёмов, поддерживаемые режимы работы, пропускная способность). 5.4.4.2. Поставщик должен указать максимальное количество логических соединений, обслуживаемых одним интерфейсом, а также целой платформой S-GW/P-GW. Поставщик должен указать рекомендуемые/максимальные значения загрузки одного интерфейса, а также целой платформы S-GW/P-GW. 5.4.4.3. Платформа S-GW/P-GW должна поддерживать интерфейсы типа 1GBASE (медные или оптические), а также типа 10GBASE (оптические), в соответствии с IEEE 802.3. 5.4.5. Техническая документация 5.4.5.1. Описание платформы S-GW/P-GW должно включать в себя доступные описания всех продуктов, относящихся к платформе. 5.4.5.2. Поставщик должен предоставить план развития платформы на 2012 год, а также на последующие 4 года (2013-2016 гг.). 5.4.5.3. Предлагаемая платформа S-GW/P-GW должна соответствовать спецификациям консорциума 3GPP Rel.9. 5.4.5.4. Поставщик должен пояснить, какие изменения в ПО и в аппаратной части повлечёт обновление платформы S-GW/P-GW для её соответствия требованиям консорциума 3GPP Rel.10. 5.4.5.5. Поставщик должен предоставить информацию о спецификациях IETF поддерживаемых платформой S-GW/P-GW (например, поддержка протокола Diameter, RFC3588). 5.4.5.6. Описанные выше критерии должны быть выполнены отдельно для следующих типов узлов: 5.4.5.6.1. только LTE сеть. Описать режим работы платформы – P-GW или S-GW или же комбинированный режим работы – SAE-GW. 5.4.5.6.2. комбинированные сети 3G/HSPA/LTE. 5.4.5.6.3. комбинированные сети 2G/3G/HSPA/LTE. 49 Поставщик должен предоставить информацию не менее, чем о трёх внедрениях платформы SAE-GW, из них должно быть не менее одного внедрения в сеть LTE. 5.4.5.8. Тестирование взаимодействия с другими производителями: 5.4.5.8.1. Поставщик должен описать результаты тестирования взаимодействия предлагаемой платформы S-GW/P-GW с оборудованием других производителей. При тестировании функционала из различных релизов консорциума 3GPP, для каждого из них необходимо предоставить отдельный документ. 5.4.5.8.2. Поставщик должен представить информацию о наличии сертификата глобального тестирования взаимодействия с оборудованием других производителей. 5.4.5.8.3. Поставщик должен предоставить сопутствующую информацию о взаимодействии предлагаемой платформы S-GW/P-GW с оборудованием других производителей, особое внимание, уделив взаимодействию с MME, eNodeB, системами провижнинга, PCRF и OCS. 5.4.5.7. 5.4.6. Основные требования к тарификации 5.4.6.1. Каждому PDP контекст/несущей должен соответствовать уникальный идентификатор для нужд биллинга. 5.4.6.2. Переданные объёмы данных должны считаться раздельно для исходящего и входящего направлений. Объёмы данных должны отражать объёмы информации, переданной пользователю и полученной от пользователя. 5.4.6.3. Механизмы тарификации должны предоставлять информацию о жизненном цикле PDP контекста/несущей. 5.4.6.4. Предлагаемая платформа S-GW/P-GW должна поддерживать управление характеристиками тарифицирования. Эти характеристики могут быть специфическими для подписки или для активного PDP контекста/несущей. 5.4.7. Онлайн-тарификация 5.4.7.1. При использовании FBC, платформа S-GW/P-GW должна сообщать данные об использовании сервиса в rating-group или в комбинации rating-groupи сервисного идентификатора. 5.4.7.2. Предлагаемое решение должно осуществлять взаимодействие с OCS в соответствии с DIAMETERCC протоколами (определёнными в технической спецификации 32.299 3GPP). 5.4.7.3. Поставщик должен предоставить детальное описание словаря для DCCA. Описание должно содержать все типы поддерживаемых DCCA сообщений (все запросы, ответы), для каждого сообщения – список всех поддерживаемых, не поддерживаемых, игнорируемых AVP, флагов AVP, значения типов AVP, допустимое количество AVP в сообщении и т.д. 5.4.7.4. Поставщик должен предоставить детальное описание всех схем, описанных ниже. Описание должно включать в себя т.н. call-flow, список всех необходимых и опциональных AVP, пример взаимодействия в .cap/.pcap формате. 5.4.7.5. Предлагаемое решение должно поддерживать пороги квот для возможности запроса дополнительной квоты до того момента, как последняя квота полностью будет использована. Локально сконфигурированный порог должен быть перезаписан если платформа S-GW/P-GW получит от OCS (Online Charging System) параметр "Time/Volume/Unit-Quota-Threshold". Локально конфигурируемый порог должен быть сконфигурирован отдельно для каждого APN. 5.4.7.6. Предлагаемое решение должно иметь возможность отключения квоты по умолчанию в конфигурации. 5.4.7.7. Предлагаемое решение должно поддерживать абонентскую переадресацию в соответствии с IETF RFC4006. 5.4.7.8. Предлагаемое решение должно поддерживать как IP, так и URL-адреса для использования в качестве адреса «сервисной страницы». 50 Предлагаемое решение должно поддерживать функциональность времени смены тарифа (как описано в IETF RFC4006). 5.4.7.10. Предлагаемое решение должно поддерживать организацию кредита (G-S-U-PoolReference AVP). 5.4.7.11. Предлагаемое решение должно поддерживать переавторизацию сообщений запросов/ответов в процессе взаимодействия с OCS. 5.4.7.12. Предлагаемое решение должно поддерживать процедуру отказоустойчивости OCS в соответствии с IETF RFC4006. 5.4.7.13. В случае ошибок при коммуникации сообщение credit-control должно быть перенаправлено в направлении альтернативного получателя в случае поддержки отказоустойчивости сервером credit-control. 5.4.7.14. Предлагаемое решение должно поддерживать следующие режимы выбора OCS: 5.4.7.14.1. Конфигурация активного/резервного OCS локально. 5.4.7.14.2. Получение данных об активном/резервном OCS через интерфейс Gx. 5.4.7.14.3. Получение данных об активном/резервном OCS от сервера AAA (RADIUS). 5.4.7.14.4. Получение данных об активном/резервном OCS от сервера AAA (DIAMETER). 5.4.7.15. Предлагаемое решение должно поддерживать все типы конфигурации OCS раздельно для каждого APN. 5.4.7.16. Предлагаемое решение должно обрабатывать следующие параметры, получаемые от OCS: 5.4.7.16.1. Granted-Service-Unit (octets/seconds/service-specific units) 5.4.7.16.2. Rating-Group 5.4.7.16.3. Service-Identifier 5.4.7.16.4. Validity-Time 5.4.7.16.5. Volume-Quota-Threshold/Time-Quota-Threshold/Unit-Quota-Threshold 5.4.7.16.6. Quota-Holding-Time 5.4.7.16.7. Quota-Consumption-Time 5.4.7.16.8. Final-Unit-Indication 5.4.7.17. Предлагаемое решение должно поддерживать отключение (блокирование или сброс) пользовательского трафика для одной или нескольких Rating-Group (или сервиса) после получения от OCS предконфигурированного Result-Code (чаще всего используются 4010 или 4012).для соответствующего MSCC (MSCC-уровень ResultCode). PDP контекст и любой другой трафик не должен быть сброшен. Значение Result-Code для этого случая должно быть конфигурируемым. 5.4.7.18. Предлагаемое решение должно быть способно деактивировать PDP контекст/несущую после получения от OCS предконфигурированного Result-Code (чаще всего используются 4010 или 4012) на командном уровне или MSCC-уровне. Значение Result-Code для этого случая должно быть конфигурируемым. 5.4.7.19. Предлагаемое решение должно быть способно осуществить переадресацию трафика для PDP контекста/несущей после получения от OCS предконфигурированного ResultCode (чаще всего используются 4010 или 4012) на командном уровне или MSCCуровне. Значение Result-Code для этого случая должно быть конфигурируемым. Адрес переадресации должен быть предконфигурирован (IP-адрес или URL-адрес). 5.4.7.20. Предлагаемое решение должно иметь возможность отправлять CCR-Initial во время активации PDP контекста/несущей для Rating-Group по-умолчанию. 5.4.7.21. Предлагаемое решение должно иметь следующий функционал: 5.4.7.21.1. Онлайн-тарификация только для заданного Заказчиком количества абонентов. 5.4.7.21.2. Один MSCC на СCR. 5.4.7.21.3. Конфигурационное значение “Cause” в IE в ответе на создание PDP контекста (любое значение из диапазона 192-255) в случае если активация PDP контекста сброшена на OCS. 5.4.7.21.4. Разделение между основным и вторичным (или вторичными) PDP контекстами в процессе онлайн-тарификации. 5.4.7.21.5. Индикация прямого туннелирования 3Gв сообщениях CCR. 5.4.7.9. 51 5.4.8. Офлайн-тарификация 5.4.8.1. Должен поддерживаться Ga интерфейс. 5.4.8.2. Поставщик должен описать поддерживаемые протоколы и механизмы, относящиеся к передаче CDR в направлении офлайновой системы тарификации (FTPpush/pull, sFTP, GTP и т.д.). 5.4.8.3. Поставщик должен описать структуру CDR, генерируемого платформой S-GW/P-GW. Для каждого элемента должны быть описаны идентификатор, длина поля, содержание. 5.4.8.4. Поставщик должен описать методы кодирования (например ASN.1 BER). 5.4.8.5. Поставщик должен описать ёмкость буферов, выделенных под CDR на платформе SGW/P-GW, если они имеются. 5.4.8.6. Поставщик должен описать механизмы надёжности CDR. 5.4.8.7. Платформа S-GW/P-GW должна иметь возможность обрабатывать тарификационные характеристики, принимаемые от SGSN/MME/HSS. 5.4.8.8. Должна поддерживаться flow-based офлайн-тарификация. 5.4.8.9. Должна поддерживаться специфическая для PDP контекста/несущей офлайнтарификация. 5.4.8.10. Предлагаемое решение должно поддерживать смену тарифного плана в соответствии со временем, днём недели и т.д. 5.4.8.11. Предлагаемая платформа S-GW/P-GW должна отправлять CDR напрямую в CGF (Charging Gateway Function). 5.4.8.12. Резервируемое хранилище CDR должно иметь встроенную возможность зеркалирования для предотвращения потери данных в случае отказа жёсткого диска в хранилище. 5.4.8.13. CDR должны быть переданы сразу после того, как произошло закрытие на запись файлов CDR. 5.5. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К DPI 5.5.1. Общие технические требования к DPI 5.5.1.1. Комплекс оборудования EPC должен обеспечивать: 5.5.1.1.1. индивидуальное управление услугами отдельных абонентов в реальном режиме времени. В случае блокировки пользователя или отдельной услуги изменения должны вступать без задержки. В случае, если пользователь использует услугу в момент блокировки/отключения, то использование должно прерываться системой; 5.5.1.1.2. динамическое изменение политик в зависимости от триггеров, поступающих от внешних и внутренних объектов, и динамическое обновление политик и действий, относящихся к конкретному абоненту; 5.5.1.1.3. возможность управления сервисами Управление Полосой Доступа и Приоритезации Трафика, т.е. сжатие полосы доступа или приоритезации трафика в соответствии с используемыми приложениями, квотой и/или состоянием prepaid баланса, уровнем нагрузки сети, профилем абонента и т.п.; 5.5.1.1.4. возможность управления сервисами тарификации – определять объемы, продолжительность или событие тарификации на базе множественных параметров, например, тип/группа приложений, время суток, категория контента, модель абонентского устройства, признак роуминга, URL, местоположение абонента и т.п.; 5.5.1.1.5. возможность получения в реальном времени информации о классификации протоколов, используемых всеми абонентами и принятия соответствующих действия на основе этой информации. 5.5.1.2. Информация, полученная в результате углубленной проверки содержимого пакетов (DPI), должна использоваться в работе сервисов, таких как: 5.5.1.2.1. контроль доступа (Access Control); 5.5.1.2.2. управление домашней страницей (Home Page Management); 52 5.5.1.2.3. перемаршрутизация (Reroute); 5.5.1.2.4. динамическое обнаружение и контроль перегрузок (Dynamic Congestion Detection and Control); 5.5.1.2.5. фильтрация контента и родительский контроль (Content Filtering and Parental Control). 5.5.1.3. Информация, полученная в результате углубленной проверки содержимого пакетов (DPI), должна использоваться в реализации сервисов управления, например, сервисов тарификации, сервисов управления квотами, сервисов управления полосой пропускания, сервисов приоритизации и пр. 5.5.1.4. Должны быть реализованы интерфейсы API для считывания данных различными системами, например, порталом оператора. 5.5.1.5. DPI должен позволять работать с туннелированным трафиком, включая трафик внутри туннеля. Кроме стандартного туннельного протокола IEEE 802.1Q VLAN, поставщик должен предоставить информацию о возможности анализа трафика внутри туннелей IP-in-IP, GRE, L2TP, GTP-U, MPLS. 5.5.1.6. DPI должен поддерживать возможность обработки с трафика в ассиметричных сценариях маршрутизации. 5.5.1.7. DPI должен обеспечивать возможность управления сервисами фильтрации контента (родительский контроль), т.е. определять категории контента с ограниченным доступом (Черные/белые URL списки) и выполнять действия, исходя из этих ограничений и категорий. Обновление списков URL должно производиться силами поставщика. При этом оператор также должен иметь возможность вносить изменения в списки URL. 5.5.1.8. DPI должен поддерживать назначение, хранение и применение параметров QoS индивидуально для каждого абонента. 5.5.1.9. DPI должен поддерживать тарификацию всех услуг, поддерживаемых биллинговой системой ЗАКАЗЧИКА в режиме postpaid и prepaid. 5.5.1.10. Поставщик должен указать способы и стоимость обновления сигнатур DPI и базы данных категорий URL фильтрации контента. 5.5.1.11. DPI должен иметь возможность по настройке отдельных веб сайтов, IP адресов, протоколов, портов, приложений, абонентских устройств, не подлежащих тарификации. 5.5.1.12. DPI должна иметь возможность настройки перенаправления блокированных абонентов, абонентов с недостаточным балансом или не активированных абонентов на отдельный веб портал оператора. А также предоставления таким абонентам доступа к личному кабинету и платежным системам. При этом на портал должны передаваться идентификаторы абонента для определения его баланса и состояния в биллинговой системе 5.5.1.13. К поставке должна быть предусмотрена система отчетности, предоставляющая возможность формирования отчетов по потреблению трафика по протоколам, URL, приложениям, агрегированные данные и данные в разрезе абонентов. 5.5.1.14. Должна быть предусмотрена возможность интеграции со сторонними сервисными системами для предоставления дополнительных сервисов посредством использования стандартных средств интеграции 5.5.1.15. В течение гарантийного срока потенциальный поставщик обязан предоставлять регулярные обновления сигнатур DPI и базы данных категорий URL фильтрации контента, Поставщик должен указать способы и стоимость обновления сигнатур DPI и базы данных категорий URL фильтрации контента в послегрантийный период. 5.5.2. Требования к производительности DPI 5.5.2.1. Платформа DPI должна иметь возможность обеспечить обслуживание 300 тыс пользователей с общей пропускной способностью до 45 Гбит/с. 5.5.2.2. Поставщик должен предоставить данные по масштабируемости DPI по следующим критериям: 53 5.5.2.2.1. Максимальная производительность (Гбит/с) при задействовании глубокого анализа пакетов для 100% трафика на 7 уровне модели OSI. 5.5.2.2.2. Максимальное количество активных в момент времени PDP контекстов/несущих. 5.5.2.2.3. Максимальное количество активаций PDP контекстов/несущих в секунду. 5.5.2.2.4. Максимальное количество деактиваций PDP контекстов/несущих в секунду. 5.5.2.2.5. Максимальное количество обновлений PDP контекстов/несущих в секунду. 5.5.2.2.6. Максимальное количество Gx транзакций в секунду. 5.5.2.2.7. Максимальное количество Gy транзакций в секунду. 5.5.2.2.8. Максимальное количество хранимых CDR. 5.5.2.2.9. Характеристики интерфейсов. 5.5.2.3. Поставщик должен описать модульность шасси DPI (возможности наращивания процессорной мощности, памяти, интерфейсов). 5.5.2.4. Поставщик должен описать возможности масштабирования по количеству IPинтерфейсов, поддерживаемых на DPI. 5.5.2.5. Поставщик должен сообщить о параметрах, негативно влияющих на производительность контрольной плоскости DPI. 5.5.2.6. Поставщик должен предоставить результаты нагрузочного тестирования DPI, если такой материал имеется. 5.5.2.7. Поставщик должен описать влияние размера пакетов на производительность DPI. 5.6. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К PCRF 5.6.1. Общие технические требования к PCRF 5.6.1.1. Оборудование (PCRF) должно соответствовать рекомендациям 3GPP Rel. 9 и выше, для стандарта LTE (Long-Term Evolution). 5.6.1.2. Система PCRF должна поддерживать те же стандарты и интерфейсы, что и в 3GPP. 5.6.1.3. PCRF должна быть совместима с 3GPP (Rel. 9) TS 29.213 политикой и потоком контроля сигнализации и качества обслуживания (QoS). 5.6.1.4. Поставляемый PCRF должен отбрасывать несовпадающие данные любой услуги при использовании правил PCRF. Должна быть обеспечена возможность определения правил PCRF оператором, с настройкой фильтров для разрешения пропуска трафика и тарификации пакетов, которые не попадают под фильтр или другие активные правила PCRF. Тарификация PCRF должна поддерживать следующие модели: Объем на основе тарификации, время на основе тарификации, время и объем на основе тарификации, событие на основе тарификации, без тарификации. 5.6.1.5. Для принятия решения по обработке трафика, должна быть обеспечена возможность различения различных типов трафика по приоритетам, или устанавливать приоритеты для индивидуальных потоков. 5.6.1.6. Должна быть обеспечена возможность создания и гибкого конфигурирования PCC правил на основе времени дня, в определенные дни, а так же на основе использования данных DPI. 5.6.1.7. Применение настроечных параметров и изменения в профилях абонентов не должно прерывать обслуживание. 5.6.1.8. Абонентские профили должны реплицироваться автоматически из UDC, либо PCRF должен обеспечивать обращение к UDC и получение запрошенных абонентских профилей. 5.6.1.9. PCRF должен поддерживать 300 000 подключенных пользователей, и иметь возможность расширения до 4 000 000 подключенных пользователей. 5.6.1.10. Поставщик должен указать поддерживаемое количество TPS (transaction per second) в поставляемой конфигурации, либо количество поддерживаемых активных PDP контекстов, либо другой параметр, определяющий производительность PCRF. 54 5.6.1.11. Должно обеспечиваться назначение различных уровней прав доступа для пользователей PCRF, например, только «чтение», «редактирование профилей абонентов». 5.6.1.12. Должен быть предусмотрен механизм управления квотами на объемы для каждого пользователя в течение определенного периода времени (например: один день/неделя/месяц), управление квотами по объему и по продолжительности, управление квотами на основе информации, предоставленной компонентом DPI . 5.6.1.13. Должна обеспечиваться возможность интеграции со сторонними производителями платформ DPI и PCRF. 5.6.1.14. PCRF должен иметь возможность по настройке отдельных веб сайтов, IP адресов, протоколов, портов, приложений, абонентских устройств, не подлежащих тарификации. 5.6.1.15. PCRF должна иметь возможность настройки перенаправления блокированных абонентов, абонентов с недостаточным балансом или не активированных абонентов на отдельный веб портал оператора. А так же предоставления таким абонентам доступа к личному кабинету и платежным системам. При этом на портал должны передаваться идентификаторы абонента для определения его баланса и состояния в биллинговой системе. 5.6.1.16. Должно быть предусмотрено наличие системы отчетности, предоставляющей возможность формирования отчетов по потреблению трафика по протоколам, URL, приложениям, агрегированные данные и данные в разрезе абонентов. 5.6.1.17. Должна быть обеспечена возможность управления PCRF и получение статистической информации о функционировании PCRF посредством OSS и с использованием стандартных протоколов, например, SNMP или Telnet. 5.6.1.18. Должна быть предусмотрена возможность интеграции со сторонними сервисными системами для предоставления дополнительных сервисов посредством использования стандартных средств интеграции. 5.6.1.19. Поставщик обязан предоставить детальное описание всех внешних интерфейсов, используемых при управлении абонентами и услугами, форматы CDR/PDR файлов, протоколов онлайн тарификации для интеграции с биллинговой системой ЗАКАЗЧИКА. В случае использовании стандартных протоколов предоставляется документ о версиях протоколов, с которым обеспечивается полная совместимость и детальная информации об отклонениях от стандарта. 5.6.1.20. Поставщик должен составить перечень всего программного обеспечения, произведенного Поставщиком, которое включается в поставляемую платформу, включая номера версий, количество установок, виды и количество необходимых лицензий и их размещение на платформе (на уровне функционального или аппаратного модуля). 5.6.1.21. Поставщик должен указать все программное обеспечение третьих сторон, на которое он получил лицензии для использования в поставляемой платформе, включая номера версий, количество установок, виды и количество необходимых лицензий и их размещение на платформе (на уровне функционального или аппаратного модуля). Поставщик несет ответственность за получение и поддержание действительности всех лицензий на программное обеспечение третьих сторон, а также за оплату всех периодических пошлин, связанных с использованием этих лицензий на программное обеспечение. 5.6.1.22. PCRF должен иметь возможность определения идентификатора обслуживающей абонента базовой станции (сектора eNodeB) при использовании услуги и передачу его в систему тарификации. Должна быть предусмотрена возможность тарификации в зависимости от района/региона обслуживания абонента. 5.6.1.23. UDC и PCRF должны поддерживать возможность выгрузки всех абонентских данных (идентификаторы абонентов, идентификаторы всех услуг и персональные настройки) в текстовом виде или в формате, совместимом с внешними базами данных, для проведения сверок с биллинговой системой ЗАКАЗЧИКА. 55 5.6.2. Требования к счётчикам и статистике 5.6.2.1. Предлагаемое решение должно генерировать данные для счётчиков не реже, чем раз в 15 минут. Статистические данные должны быть доступны через систему OSS. 5.6.2.2. Предлагаемое решение должно поддерживать экспорт статистической информации во внешние системы посредством файлов формата «*.csv» или интерфейсов к базам данных. 5.6.2.3. Предлагаемое решение должно иметь возможность предоставлять необходимые данные в режиме реального времени: 5.6.2.3.1. Количество активаций/деактиваций PDP контекстов 5.6.2.3.2. Количество подсоединённых пользователей 5.6.2.3.3. Количество открытых PDP контекстов 5.6.2.3.4. Производительность на один PDP контекст 5.6.2.3.5. Статистика CDR 5.6.2.3.6. Статистика виртуальных соединений 5.6.2.3.7. Статистика пейджинга 5.6.2.3.8. Счётчики, ассоциированные с интерфейсом Gx 5.6.2.4. Отчёты должны содержать в себе: 5.6.2.4.1. Идентификатор абонента: IMSI 5.6.2.4.2. Идентификатор мобильного устройства: IMEI 5.6.2.4.3. Информацию о местоположении: LAC, RAC, Cell Id, SAC 5.6.2.4.4. Причины ошибок 5.6.2.4.5. APN 5.6.2.4.6. P-GW IP-адрес 5.6.2.4.7. Тарификационная информация 5.6.2.4.8. Объём данных (байт) на PDP контекст UL/DL 5.6.2.4.9. Запрошенный/установленный QoS профиль 5.6.3. Общие требования 5.6.3.1. Поставщик должен предоставить план основных релизов и всех дополнительных функции на период следующих 5 лет, который должен включать в себя все основные и дополнительные функции, а также потенциально-возможные не стандартизованные решения. 5.6.3.2. Поставщик обязуется, что поставляемое аппаратное обеспечение будет поддерживать новые версии программного обеспечения и функционал без необходимости изменения основных аппаратных средств (за исключением интерфейсных карт) на ближайшие пять лет. 5.6.3.3. По истечении этого срока поставщик обязан поддерживать последнюю версию ПО с патчами и исправлениями ошибок, по крайней мере в течении двух лет. 5.6.3.4. Поставщик должен предоставить список поддерживаемых стандартов для всех протоколов и функций, и подробные спецификации для всех не стандартизованных протоколов и функциональности (SoC). 5.6.3.5. Список должен содержать детализированную информацию о полном и частичном соответствии техническим спецификациям с указанием их версий. 5.6.3.6. Поставщик по требованию заказчика должен согласовать выпуск обновления ПО для обеспечения взаимодействия с решениями 3х сторон. 5.6.3.7. PCRF должен игнорировать любые полученные нераспознанные поля или значения с оборудования других производителей. Получение такого поля или значения не должно оказывать влияния на предоставляемые сервисы. 5.6.3.8. PCRF должен генерировать дополнительные отчеты о факте получения нераспознанного поля или значения на любом интерфейсе. 56 5.6.4. IOT 5.6.4.1. Поставщик должен взять на себя ответственность за IOT своего оборудования с оборудованием всех интегрируемых узлов сторонних производителей в рамках PCRF решения. 5.6.4.2. Результаты проверки IOT предоставляются по окончании проведения тестирования. 5.6.4.3. Результаты любых IOT тестов, проведенных с оборудованием других вендоров, которое используется в сети оператора, независимо от заказчика, должны предоставляться поставщиком. 5.6.4.4. Статический и динамический ChargingControl. PCRF должен поддерживать статический (при старте контекста, установлении defaultbearer) и динамический (в середине сессии, при создании дополнительных bearer) ChargingControl на уровне Bearer/Flow. 5.6.4.5. Статические и динамические политики. PCRF должен поддерживать статические и динамические политики на уровне Bearer/Flow. 5.6.4.6. PolicyPeering. PCRF должен поддерживать политику пиринга между домашним и роуминговым PCRF узлами. 5.6.4.7. Создание голосовых и неголосовых bearer. PCRF должны поддерживать создание голосовых и неголосовых bearer и контроль QoS и пропускной способности ядра сети и радиосети. 5.6.5. Логические интерфейсы. DIAMETER интерфейсы 5.6.5.1. Gx. PCRF должен поддерживать интерфейс Gx с PDN GW в соответствии с 3GPP 23.203, 29.210, 29.212 и 29.213. Поставщик должен указать поддерживаемую версию и предоставить StateofComliance документ и любую другую релевантную. 5.6.5.2. Rx. PCRF должен поддерживать интерфейс Rx AF, соответствующий спецификациям 3GPP 23.203, 29.212 и 29.214. Поставщик должен указать поддерживаемую версию и предоставить StateofComliance документ и любую другую релевантную. 5.6.5.3. Volumeover Gx. PCRF должен поддерживать возможность квотирования по трафику и отчетности посредством Gx интерфейса в соответствии с 3GPP 29.212. 5.6.6. Policy Engine 5.6.6.1. Входная информация для Policy Engine 5.6.6.1.1. Входная информация для формирования политик - TS 23.203. PCRF должен принимать информацию, описанную в 3GPP TS 23.203 в качестве входных данных для формирования политик. Поставщик должен описать, какой интерфейс / протокол / информационный элемент (например, Gx / диаметр / AVP, Sp / LDAP / класса / атрибута) используется для передачи информации. 5.6.6.1.2. Гибкие настройки протокола. Протокол / информационные элементы интерфейса ввода должен быть настраиваемым, например, по словарю и не может быть жестко задан. Поставщик должен предоставить документацию по гибкой настройке протоколов / информационных элементов. 5.6.6.1.3. Другие источники входных данных. Поставщик должен предоставить информацию о других источниках входных данных, используемых PCRF узлом для формирования политик. 5.6.6.1.4. Source IP. PCRF должен иметь возможность использовать bearerSource IP в качестве входной информации для формирования политики. 5.6.6.1.5. IMSI. PCRF должен иметь возможность использовать IMSI в качестве входной информации для формирования политики. 5.6.6.1.6. IMEISV. PCRF должен иметь возможность использовать IMEISV в качестве входной информации для формирования политики. 5.6.6.1.7. SubscriberTier. PCRF должен иметь возможность использовать SubscriberTier параметр (например, Gold, Silver, Bronze) в качестве входной информации для формирования политики. 57 5.6.6.1.8. User-Time-Zone. PCRF должен иметь возможность использовать информацию о часовом поясе абонент в качестве входных данных для формирования политики. 5.6.6.1.9. Location. PCRF должен иметь возможность использовать UserLocation / RoamingStatus (MNC, MCC, RAC, LAC, Cell Id) в качестве входных данных для формирования политики. 5.6.6.1.10. Технология доступа. PCRF должен иметь возможность использовать информацию о технологии доступа (RAT-Type -UTRAN, GERAN, WLAN)в качестве входных данных для формирования политики. 5.6.6.1.11. Rx интерфейс. PCRF должен иметь возможность использовать информацию с Rx интерфейса в качестве входных данных для формирования политики. 5.6.6.1.12. Sp интерфейс. PCRF должен иметь возможность использовать информацию с Sp интерфейса в качестве входных данных для формирования политики. 5.6.6.1.13. APN. PCRF должен иметь возможность использовать информацию об используемом APN в качестве входных данных для формирования политики. 5.6.6.1.14. Информация об абоненте. PCRF должен иметь возможность использовать информацию об абоненте из пользовательского профиля в качестве входных данных для формирования политики. 5.6.6.2. Внутренние триггеры Policy Engine 5.6.6.2.1. Внутренние таймеры. PCRF должен иметь возможность использовать внутренние таймеры (начала и окончания периода) в качестве входных данных для формирования политики. 5.6.6.2.2. Время/день недели/дата. PCRF должен иметь возможность использовать время суток, день недели/месяц, день месяца, рабочие дни, выходные в качестве входных данных для формирования политики. 5.6.6.2.3. Состояние внешних связей. PCRF должен иметь возможность использовать информацию о состоянии соединения (например, TCP, диаметр Watchdog, LDAP сессии) в качестве входных данных для формирования политики. 5.6.6.2.4. Нахождение в роуминге. PCRF должен иметь возможность идентифицировать нахождение абонента в роуминге с помощью внутренней таблицы соответствий между S-GW IP-адрес (IPv4 / IPv6) и гостевой сети, в которой S-GW находится. 5.6.6.2.5. Политики по умолчанию. PCRF должен поддерживать назначение предопределенных политик по умолчанию в случае отсутствия дополнительных системы (такие как SPR). 5.6.7. Логика программирования 5.6.7.1. Гибкий язык программирования логики. PCRF должен включать в себя гибкий программируемый логический язык, чтобы объединить внешнюю и внутреннюю информацию/триггеров и формирования выходных политик. Поставщик должен предоставить описание возможностей языка 5.6.7.2. Графический интерфейс. PCRF должен включать в себя графический интерфейс, позволяющий наглядно формировать логические блоки, участвующие в построении политик. 5.6.7.3. Предварительная проверка конфигурации. PCRF должен иметь возможность автоматической проверки корректности сформированной конфигурации политик (проверка синтаксиса, параметров). 5.6.8. Выходная информации Policy Engine 5.6.8.1. Интерфейсы к нескольким PCEF. Помимо поддержки первичного PCEF с интерфейсом Gx, PCRF должен поддерживать несколько вторичных PCEF. 5.6.8.2. Выбор OCS. PCRF должен поддерживать возможности выбора основной/резервной системы онлайн тарификации в сформированной политике. 58 Context/Bearer Control. PCRF должен поддерживать возможности (установка, разрыв, QoS, полоса пропускания, QCI) на основе потоков данных услуг в сформированной политике. 5.6.8.4. Сharging-rule-base-name AVP. PCRF должен поддерживать возможности назначения одного из нескольких rule-base. 5.6.8.5. Сharging-rule AVP. PCRF должен поддерживать возможность одновременного назначения нескольких rule. 5.6.8.6. Charging-Rule-Definition AVP. PCRF должен поддерживать возможность назначения динамически сформированных правил. 5.6.8.7. policy validity time. PCRF должен поддерживать возможность назначения времени, до которого будет действовать назначенное правило. 5.6.8.8. Event Triggers. PCRF должен поддерживать назначение триггеров событий на PCEF, как указано в 3GPP TS 23.203. 5.6.8.9. QCI, определенные оператором. PCRF должен поддерживать возможность назначение со стороны оператора значений QCI. 5.6.8.10. Модификация default-bearer во время attach. PCRF должен поддерживать возможность модификации параметров default-bearer в момент процедуры attach. 5.6.8.11. Модификация параметров активной сессии. PCRF должен поддерживать возможность модификации service-data-flow QoS параметров уже установленной сессии. 5.6.8.12. Модификация APN-AMBR установленной сессии. PCRF должен поддерживать возможность модификации параметров APN-AMBR уже установленной сессии. 5.6.8.3. 5.6.9. High Availability 5.6.9.1. Поставщик должен гарантировать, что поставляемые сетевые элементы PCRF и системы удовлетворяют требованиям по надежности/отказоустойчивости 0,99999. 5.6.9.2. Резервное копирование, техническое обслуживание и модернизация системы осуществляется без перебоев в предоставлении услуг. 5.6.9.3. Описание концепции доступности. Поставщик должен направить описание концепции доступности. 5.6.9.4. Отсутствие потери информации о состоянии в случае отказа. В случае отказа любой карты, интерфейса или процесса, информация о состоянии абонента должна постоянно поддерживаться. Любые возможные потери информации о состоянии должны быть определены и четко заявлены для заказчика. 5.6.9.5. Отсутствие потери информации о сессии в случае отказа. Отказоустойчивый переход с активной карты на карту в режиме ожидания, или аналогичный переход для интерфейсов, процессов или узлов должен осуществляется без потери данных для любой сессии по протоколу DIAMETER, сессий базы данных или любой другой сессии. 5.6.9.6. Выполнение конфигурационных команд. Выполнение конфигурационных команд не должно приводить к перебоям в предоставлении услуг 5.6.9.7. Частичное изменение конфигурации без изменения всей конфигурации. Решение должно поддерживать возможность изменения конфигурации любой части системы без необходимости удаления всего или части предыдущей конфигурации. Это необходимо, чтобы избежать потери в предоставлении услуг при изменении конфигурации. 5.6.9.8. Частичное изменение конфигурации без перезагрузки. Должна быть возможность изменять любую часть конфигурации системы без необходимости перезагрузки или сброса карты или всей системы. Где это не возможно, должно быть ясно указано. 5.6.9.9. Реконфигурация / переключение интерфейсов, в случае сбоя карты. Реконфигурация / переключение интерфейсов, в случае отказа карты не должна занимать больше, чем 1 секунду для любого из поддерживаемых протоколов 5.6.9.10. реконфигурация / переключение интерфейсов, в случае сбоя канала связи. Реконфигурация / переключение интерфейсов, в случае отказа канала связи не должна занимать больше, чем 1 секунду для любого из поддерживаемых протоколов 59 5.6.9.11. Предотвращение сбоев связи. Поставщик должен описать возможности PCRF по преодолению сбоев связи, чтобы сохранить доступность услуг. 5.6.10. Возможности по созданию Сервисов 5.6.10.1. Поставщик должен перечислить список сервисов доступных для реализации. Предоставить примеры и алгоритмы реализуемых сервисов. Примеры обязательных сервисов: 5.6.10.1.1. Турбо-кнопка – Обеспечение гарантированного QoS (скорости) на заданный период времени для заданных протоколов. 5.6.10.1.2. Управление IP сервисами (разрешить/запретить) 5.6.10.1.3. Многоуровневые сервисы 5.6.10.1.4. Установление заданного QoS для определенного контента. 5.6.10.1.5. Управление QoS для голосовых IMS сервисов ( Rx) 5.6.10.1.6. Контроль потребляемого объема трафика за заданный период времени с ограничением полосы по превышению объема (FairUsage) 5.6.10.2. Поставщик должен предоставить описание возможностей по управлению, например как решение поддерживает следующий сценарий: Реализация применения Fair-Usage политик с ограничением объема трафика 5Гбайт в месяц. По достижении лимита по объему применяется политика ограничения полосы пропускания на 50% для всего пользовательского трафика (за исключением внутренних сервисов оператора) и перенаправление на портал для информирования абонента о достижении лимита. Дополнительно возможна отправка SMS. Требуется описать логику работы PCRF с соответствующими диаграммами сообщений (flowdiagram), используемыми интерфейсами и AVP. 5.6.10.3. Подписка на доступ к сервисам. Данный сервис предполагает возможность для абонента выполнить и оплатить подписку на доступ к определенным сервисам. Доступ к сервисам запрещен до оплаты подписки. Поставщик должен представить описание логики работы сервиса с учетом следующих требований: 5.6.10.4. PCRF должен иметь доступ в реальном времени к информации об активных подписках пользователя. 5.6.10.5. PCRF должен контролировать истечение подписки по времени или объему с выполнением перенаправления HTTP-трафика пользователя на информационный портал или ограничением полосы пропускания. 5.6.10.6. Подписка должна быть привязана к определённому типу сервиса/протокола и/или местоположению абонента (роуминг). 5.6.10.7. PCRF должен взаимодействовать с пользовательским порталом для осуществления подписки. 5.6.10.8. PCRF должен обеспечивать оперативную реакцию на изменение подписки для применения соответствующих политик обслуживания. 5.6.10.9. PCRF должен обрабатывать триггеры событий от внешних систем с индикацией изменений в абонентской сессии, балансе пользователя и изменении подписок. 5.6.10.10. PCRF должен получать данные пользовательского профиля и сохранять локально до окончания пользовательской сессии. 5.7. ТРЕБОВАНИЯ К ETHERNET КОММУТАТОРАМ 5.7.1. Обеспечить соединение всех элементов EPC, внешних подсистем (Биллинг, СОРМ) и транспортной сети RAN в единое целое с обеспечением высокой надежности и резервирования, должно быть не менее 12 интерфейсов 10GE, 10 интерфейсов 1GE. 5.7.2. Обеспечение поддержки следующих интерфейсов: 5.7.2.1. 100/1000MBASE-T RJ-45; 5.7.2.2. SFP/SFP+/XENPAK/X2 порты с обеспечением скорости 1000M и 10GBASE 5.7.3. Обеспечивать поддержку использования VLAN 5.7.4. Поддержка объединения в стек (виртуализация) нескольких коммутаторов 60 5.7.5. Поддерживать использование QoS на уровнях L2/L3. 5.7.6. Поддержка Jumbo Frame 5.7.7. Должно быть предусмотрено для подключения с Mobile Backhaul – не мене 6 интерфейсов 10GE. Для интеграции с биллинговой системой не менее 8 интерфейсов 1GE. 5.7.8. Поставка должна включать в себя как минимум 2 отдельных физических коммутатора. Каждый из которых должен обеспечить поддержку: № Наименование Спецификация 1 Switching capacity Не менее 720 Gbps 2 Количество VLAN Не менее 4096 (IEEE 802.1q) 3 Отказоустойчивость Поддержка VRRP, IEEE 802.3ad (LACP) 5.7.9. Требования к UNI 5.7.9.1. На интерфейсах подключения EPC к сети MBH должен быть реализован стык «абонент-сеть» (UNI – User to Network Interface), определяющий точку разграничения полномочий; 5.7.9.2. На интерфейсах подключения ЕРС к сети МВН должен быть реализован IPv4 UNI; 5.7.9.3. Мультиплексирование IPv4 сервисов должно осуществляться с помощью VLAN тегов 802.1Q. 5.7.10. Требования к составу сервисов 5.7.10.1. На интерфейсах агрегирующих коммутаторов EPC должны быть реализованы следующие телекоммуникационные сервисы (отдельные VLAN): 5.7.10.1.1. S1-C – сервис для трафика контрольного уровня LTE интерфейса S1; 5.7.10.1.2. S1-U – сервис для трафика уровня данных LTE интерфейса S1; 5.7.10.1.3. MGMN – сервис для трафика управления устройствами уровня MNO (management); 5.8. ТРЕБОВАНИЯ К ОБОРУДОВАНИЮ FIREWALL 5.8.1. Обеспечивать поддержку использования протокола NAT и NAPT при предоставлении услуг доступа к сети Интернет. 5.8.2. Система NAT44 должна быть предназначена для трансляции адресов протокола IPv4 в пакетах данных пользователей LTE при доступе таких пользователей в сеть Интернет; 5.8.3. В состав Системы должна входить система хранения и обработки сообщений о трансляциях; 5.8.4. Система хранения должна позволять обрабатывать, хранить и выгружать данные о совершенных трансляциях за 3 месяца. 5.8.5. Должна быть приведена оценка необходимого объёма и производительности системы хранения в зависимости от предложенного способа хранения и обработки сведений о трансляциях. 5.8.6. Система хранения должна позволять выгружать все или часть данных в основное хранилище данных Заказчика. 5.8.7. Суммарная производительность оборудования при трансляции адресов в предложенной конфигурации должна составлять не менее 45Гбит/с c возможностью дальнейшего расширения; 5.8.8. Количество одновременно транслируемых Системой сессий должно составлять не менее 10М; 5.8.9. Поставщик должен предоставить информацию о возможности увеличения емкости системы трансляции адресов до пропускной способности суммарно до 400Гбит/с; 5.8.10. Система в целом должна отвечать следующим требованиям по трансляции адресов и адресных семейств: 5.8.10.1. поддерживать Carrier-Grade NAT (NAT44) IPv4 в соответствие с рекомендациями RFC4787, RFC5382 и RFC5508 61 5.8.10.2. поддерживать Carrier-Grade трансляцию между адресными семействами IPv4 и IP6, включая: 5.8.10.3. 6rd Border Relay, для IPv6 Rapid Deployment (RFC5969); 5.8.10.4. stateful и stateless IPv4/IPv6 трансляция на основе спецификаций группы IETF BEHAVE (AFT NAT64, DNS64); 5.8.11. Поддерживать следующие Application Level Gateway (ALG): BOOTP, DCE RPC и DCE RPC portmap, RPC и RPC portmap, Exec, FTP, H.323, ICMP, IIOP, login, NetBIOS, NetShow, RealAudio, RTSP, shell, SNMP, SQLNet, Trivial File Transfer Protocol (TFTP), traceroute, WinFrame, SIP. 5.8.12. Поддерживать блочное и динамическое выделение портов TCP/UDP при трансляции; 5.8.13. Поддерживать трансляцию потоков данных пользователей различных VPN. 5.8.14. Потенциальный Поставщик должен предложить решение для реализации функции Security Gateway для подключения eNodeB (с поддержкой не менее 1000 IPSec туннелей с возможностью дальнейшего расширения до 10000) 5.9. ТРЕБОВАНИЯ К МАРШРУТИЗАТОРАМ EPC. 5.9.1. Общие требования. 5.9.1.1. Маршрутизаторы ядра EPC должны обеспечить маршрутизацию и агрегацию интерфейсов элементов EPC. 5.9.1.2. Для обеспечения надежности, поставка должна включать 2 физических устройства способных обслуживать весь трафик при выходе одного из них из строя. 5.9.1.3. Маршрутизаторы должны поддерживать подключение к OSS EPC и обеспечивать передачу аварийных сигналов и передачу статистической информации по всем портам и основным ресурсам. 5.9.2. Требования к производительности. 5.9.2.1. Каждый из двух маршрутизаторов должен отвечать следующим требованиям по производительности и функционалу: № Наименование Спецификация 1 Протоколы Fast Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet 2 Типы интерфейсов Электрические 100/1000М, оптический 1/10GE 3 Switching capacity Не менее 700 Gbps 4 IPv4/IPv6 routing Не менее 500 Mpps capacity 5 Routing Protocol OSPF, RIP, BGP-4, IS-IS, IGMP, PIM-SM, PIM-DM 6 Дополнительные Layer 3 switching, layer 2 switching, DHCP support, MPLS функции support, VLAN support, IGMP snooping, DoS attack prevention, Access Control List (ACL) support, Quality of Service (QoS), MPLS VPN, Virtual Route Forwarding-Lite (VRF-Lite) 7 Соответствие IEEE 802.1x стандартам 8 Количество портов, 100М – 5шт не менее 1G – 10шт 10G – 8шт маршрутизаторы должны обладать масштабируемостью, то есть в предлагаемой конфигурации должно быть задействовано не более 50% слотов 62 5.10. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ ЭЛЕКТРОПИТАНИЯ EPC 5.10.1. Общие технические требования к системе электропитания EPC 5.10.1.1. Эффективность системы должна составлять не менее 94% при 100% нагрузке. 5.10.1.2. Входное напряжение переменного тока 80В -300В. 5.10.1.3. Выходное номинальное напряжение постоянного тока 48В, установленное от 42,0 до 58,0В. 5.10.1.4. Система должна обеспечивать подачу оповещающих (звуковых и визуальных) сигналов разряда аккумуляторных батарей. 5.10.2. Требования к системам электропитания EPC Параметры систем электропитания постоянного тока. Система питания постоянного тока должна: 5.10.2.1. Состоять из двух (основной и резервной) систем электропитания преобразования напряжения переменного тока в напряжение постоянного тока типа AC-DC. 5.10.2.2. Иметь блок распределения переменного и постоянного тока, выпрямители и системный блок управления. 5.10.2.3. Обеспечивать (основная и резервная) достаточную мощность всего комплекса поставляемого Поставщиком оборудования, с учетом 25%-го запаса и возможностью дальнейшего модульного расширения. 5.10.2.4. Продолжительно работать при напряжении трехфазной сети 340-440В и однофазной сети 170-253В. 5.10.2.5. Работать без риска повреждения в диапазоне трехфазного напряжения 310-460В и однофазного напряжения 179-265В, при частоте 47-63 Гц, при температуре от -10 до +50°С. 5.10.2.6. Быть оборудована системой «мягкий» пуск, т.е. системой гашения всплесков коммутационных токов. 5.10.2.7. Обеспечивать автоматический запуск при появлении входного переменного напряжения независимо от уровня заряда/разряда аккумуляторных батарей. 5.10.2.8. Иметь выходное напряжение постоянного тока с буферным подключением батарей в режиме постоянного подзаряда, регулируемое в пределах 42-58В и режима ускоренного заряда 54-56В. 5.10.2.9. Иметь флуктуацию выхода не более ±60мВ при изменении входного напряжения сети 360-440В, при 10% и 100% нагрузке. 5.10.2.10. Обеспечивать работу блоков без риска повреждения при коротком замыкании на выходе и автоматически восстанавливать выходное напряжение при пропадании короткого замыкания. 5.10.2.11. Иметь стабильность выхода (изменение выхода менее 5% при изменении нагрузки от 10 до 90% и от 90% до 10% в период времени не более 10 мсек.). 5.10.2.12. Иметь двухступенчатый контроль уровня разряда батарей и автоматическое отключение батареи от нагрузки при низком напряжении батареи. 5.10.2.13. Иметь контроль заряда батарей и режим ускоренного заряда (программный заряд). 5.10.2.14. Иметь сигнализацию нормальной работы системы и аварийного состояния (местной, аудио и удаленной, через «сухие» контакты): 5.10.2.14.1. пропадание входной сети переменного тока по фазам; 5.10.2.14.2. авария выпрямителей; 5.10.2.14.3. отсутствие выпрямителей; 5.10.2.14.4. высокая температура; 5.10.2.14.5. низкое напряжение батареи; 5.10.2.14.6. отключение батарей по низкому напряжению. 5.10.2.15. Иметь класс защиты между входом и выходом системы, соответствующий требованиям VDE 0804 и IEC 0950. 63 5.10.2.16. Иметь электрическую изоляцию между вводом и корпусом и выходом и корпусом не менее 20МОм при напряжении до 500 В. 5.10.2.17. Иметь электрическую прочность изоляции, соответствующую требованиям IEC 950, EN60950. 5.10.3. Системы распределения питания по постоянному току. 5.10.3.1. Системы распределения питания по постоянному току должны: 5.10.3.1.1. состоять из отдельного шкафа (стойки) распределения нагрузки напряжения постоянного тока DC-48В с автоматическими выключателями защиты, в количестве и номиналами, достаточными для подключения питания всего комплекса, поставляемого Поставщиком оборудования. 5.10.3.1.2. иметь класс защиты между входом и выходом системы, соответствующий требованиям VDE 0804 и IEC 0950; 5.10.3.1.3. иметь электрическую изоляцию между вводом и корпусом и выходом и корпусом не менее 20 МОм при напряжении до 500 В; 5.10.3.1.4. иметь электрическую прочность изоляции, соответствующую требованиям IEC 950, EN60950. 5.10.4. Требования к системе гарантированного электропитания переменного тока Система гарантированного питания переменного тока (инверторная система типа АС-АС, DCАС) должна: 5.10.4.1. Состоять из двух (основной и резервной) систем электропитания преобразования входного напряжения переменного тока в гарантированное напряжение переменного тока типа AC-АC, с применением технологии EPC (улучшенное преобразование энергии), серии TSI (Twin Sine Inverter). 5.10.4.2. Иметь блок распределения переменного и постоянного тока, инверторы и системный блок управления. 5.10.4.3. Обеспечивать (основная и резервная) достаточную мощность всего комплекса, поставляемого Поставщиком оборудования, с учетом 25%-го запаса и возможностью дальнейшего модульного расширения. 5.10.4.4. Иметь входное напряжение: АС – 380/220В, 3-х фазное, 50 Гц - основное питание. Разброс входного напряжения без перехода на батареи 185-265 В., DC – 48В резервное питание при отсутствии основного питания. Разброс входного напряжения 40-60 В. 5.10.4.5. Иметь выходное напряжение: синусоидальное 230В, возможность регулирования в пределах 200-240 В, частота 50 Гц., Нестабильность напряжения -2%. 5.10.4.6. Иметь визуальную сигнализацию: 5.10.4.7. наличие входного напряжения, 5.10.4.8. наличие выходного напряжения, 5.10.4.9. перегрузка, нарушение работы. 5.10.4.10. Иметь автоматическое переключение, в зависимости от предварительно выбранного режима работы. 5.10.4.11. Переключать нагрузку за время, не более 1,5 мс, на резервное питание DC 48В при пропадании основного питания сети АС 380 В. 5.10.4.12. Иметь класс защиты между входом и выходом системы, соответствующий требованиям VDE 0804 и IEC 0950. 5.10.4.13. Иметь электрическую изоляцию между вводом и корпусом и выходом и корпусом не менее 20 МОм при напряжении до 500 В. 5.10.4.14. Иметь электрическую прочность изоляции, соответствующую требованиям IEC 950, EN60950. 5.10.4.15. Иметь шкаф (стойку) распределения нагрузки напряжения переменного тока АC400/230В с автоматическими выключателями защиты, в количестве, достаточном для подключения питания всего комплекса, поставляемого Поставщиком оборудования 64 АС-DC -48 380/220 Рез. АС DC-AC 220 Рис. 5.1 Схема организации электропитания 5.10.5. Требования к исполнению 5.10.5.1. Модульное исполнение блоков выпрямителей с резервирование по схеме не менее n+1; 5.10.5.2. Местное и дистанционное управление с возможностью интеграции в OSS; 5.10.5.3. Контрольная панель должна обслуживаться без отключения стойки питания; 5.10.5.4. Устройство управления и контроля должно быть оборудовано монитором с дисплеем для установки следующих параметров: 5.10.5.4.1. выходное напряжение; 5.10.5.4.2. емкость батарей; 5.10.5.4.3. режим заряда батарей (ускоренный и стандартный); 5.10.5.4.4. входное напряжение переменного тока по фазам; 5.10.5.4.5. выходное напряжение; 5.10.5.4.6. ток нагрузки; 5.10.5.4.7. ток по блокам; 5.10.5.4.8. температура блоков выпрямителей; 5.10.5.4.9. емкость в % при заряде батарей в каждой группе. 5.10.6. Технические требования к аккумуляторным батареям 5.10.6.1. Емкость аккумуляторных батарей должна обеспечивать бесперебойную работу оборудования по постоянному и переменному току не менее 12 часов (при t° 20°С). 5.10.6.2. Удовлетворять требованием по току и напряжению для обеспечения нормальной работы оборудования во время отключения входного напряжения 220/380 В. 5.10.6.3. В целях устойчивой работы системы и обслуживания, должно быть не менее 4-х групп батарей. 5.10.6.4. Батареи должны быть герметичными, необслуживаемыми со сроком службы не менее 7 лет. 5.10.6.5. Рабочий диапазон температур от -10°С до +50°С. 5.10.6.6. Доступ к монтажу батарей должен быть с лицевой стороны. 5.10.6.7. В случае внешнего исполнения (установка вне стойки питания) аккумуляторные батареи должны комплектоваться аккумуляторными шкафами/стеллажами. 5.10.7. Технические требования к стационарному дизель генератору 5.10.7.1. Дизель-электрическая установка (ДЭУ), контейнерного типа в соответствии с требованиями по автоматизации по 1-ой степени, должна иметь применение в качестве резервного (аварийного) источника электроэнергии стационарного исполнения для электроснабжения трехфазным током частотой 50Гц, напряжением 400В. 5.10.7.2. Мощность ДЭУ должна обеспечивать достаточную мощность всего комплекса поставляемого Поставщиком оборудования, с учетом 30%-го запаса 65 5.10.7.3. Иметь встроенный топливный бак ёмкостью, обеспечивающий работу ДЭУ не менее 72 часов. 5.10.7.4. Систему подогрева масла 5.10.7.5. Систему подогрева топлива 5.10.7.6. Систему автоматический прием нагрузки 5.10.8. Общие требования 5.10.8.1. Наличие сертификата соответствия Республики Казахстан на системы бесперебойного питания, аккумуляторным батареям и дизель генератору. 5.10.8.2. Местное и дистанционное управление с возможностью интеграции в OSS; 5.10.8.3. Наличие инструкции по монтажу и эксплуатации. 5.10.8.4. Срок гарантии на оборудование не менее 24 месяцев. 5.10.8.5. Обеспечение пост гарантийным ремонтом. 66 6. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К RAN 6.1. ОБЩИЕ ТРЕБОВАНИЯ К RAN Оборудование RAN (radio access network) является частью сети стандарта LTE. Для построения RAN используются базовые станции LTE - eNodeB. В Табл.2.1 приведено количество eNodeB планируемое для построения RAN в Алматы и Астана. eNodeB будут устанавливаться как на существующих объектах Заказчика, так и на новых объектах. Для построения RAN в Алматы и Астана будет использоваться частотный диапазон 1800МГц. Согласно классификации 3GPP: Band 3 (1710 - 1785/1805 - 1880МГц). Режим FDD LTE (частотное разделение дуплексных каналов). Выделенные частоты: полоса частот передачи в направлении «от абонента» – 1765 - 1785 МГц; полоса частот передачи в направлении «к абоненту» – 1860 - 1880 МГц; ширина полосы рабочих частот – 2х20МГц. Должна быть обеспечена поддержка использования частотного диапазон 800МГц согласно классификации 3GPP: Band 20 (832-862/791-821МГц). Режим FDD LTE (частотное разделение дуплексных каналов), ширина полосы рабочих частот – 2х5МГц. Сети доступа RAN должны обеспечить обслуживание до 150тыс. абонентов в регионе Алматы и 75тыс. абонентов в регионе Астана. В целях номинального планирования радиосети может быть принято, что мобильные абоненты будут распределены по территории покрытия радиосети согласно имеющейся информации о типах застройки территории. 6.1.1. Общие технические требования к оборудованию eNodeB 6.1.1.1. Оборудование eNodeB должно соответствовать рекомендациям 3GPP Rel. 9 и выше для стандарта LTE. 6.1.1.2. Потенциальный поставщик должен предоставить план развития продукта, четко указать версию программного обеспечения (не коммерческую и коммерческую), структурные изменения сети, усовершенствования, поддерживаемые интерфейсы, новые возможности; 6.1.1.3. Потенциальный поставщик должен подробно описать основные преимущества предлагаемых базовых станций eNodeB, которые он желает подчеркнуть; 6.1.1.4. Потенциальный поставщик должен предоставить следующие общие документы с описанием оборудования и решения сети LTE: 6.1.1.4.1. Описание программного функционала оборудования 6.1.1.4.2. Техническое описание продукта 6.1.1.5. Оборудование eNodeB должно обеспечивать максимальную суммарную пропускную способность на сектор не менее 150 Мбит/с в направлении «к абоненту» и не мене 50 Мбит/с в направлении «от абонента», при ширине канала 20 МГц, суммарная пропускная способность должна быть не менее DL 300Мбит/с, UL 100Мбит/с на каждый eNodeB. 6.1.1.6. Оборудование eNodeB должно обладать высокой производительностью, высокой степенью интеграции и сконструировано с использованием принципов модульного дизайна. 6.1.1.7. Построение eNodeB должно базироваться на мультистандартном и мультичастотном принципе. Поставщик должен предоставить сведения о возможности поддержки поставляемым решением eNodeB радио-интерфейсов LTE в диапазоне частот 800/850 МГц, а также GSM/HSPA в диапазонах частот 1800 и 800/850 МГц. Поставщик также должен предоставить сведения о характере модернизации поставляемого решения eNodeB, необходимой для реализации вышеуказанных технологий в различных диапазонах частот. 6.1.1.8. Поставляемое оборудование eNodeB должно обеспечивать развертывание трехсекторной конфигурации eNodeB на каждом Сайте RAN. 67 6.1.1.9. 6.1.1.10. 6.1.1.11. 6.1.1.12. 6.1.1.13. 6.1.1.14. 6.1.1.15. 6.1.1.16. 6.1.1.17. 6.1.1.18. 6.1.1.19. 6.1.1.20. 6.1.1.21. 6.1.1.22. 6.1.1.23. Оборудование eNodeB должно поставляться в конструктивном исполнении «Distributed eNodeB» - с разделением компонентов и поддержкой 2x2 MIMO. Должны обеспечиваться интерфейсы в направлении EPC и в направлении абонентского оборудования (BBU и RRU соответственно). При этом должна быть обеспечена возможность установки RRU как внутри, так и вне Сайта. Потенциальный поставщик должен предоставить информацию о коммерческой доступности продуктовой линейке eNodeB с отражением сведений о модельном ряде от Macro до Femto и приложением соответствующих технических характеристик. Оборудование eNodeB должно поддерживать функционал SON (Self Organizing Networks) согласно спецификациям 3GPP rel.9 и выше для упрощения настройки и оптимизации параметров RAN. Оборудование eNodeB должно быть оснащено последовательными портами для передачи на устройства более высокого уровня сообщений об авариях компонентов или системы в целом в случае отказа штатных линий/каналов связи. Оборудование eNodeB должно поддерживать дистанционное/локальное техническое обслуживание. Оборудование eNodeB должно поддерживать синхронизацию IEEE 1588v2. Потенциальный поставщик должен указать и описать возможности механизмов обеспечения высокой степени надежности и гибкой масштабируемости решения базовых станций eNodeB. Оборудование eNodeB должно соответствовать требованиям к электромагнитной совместимости, определенным стандартом ETSI EN 300 386 «Electromagnetic compatibility and Radio spectrum Matters (ERM) - Telecommunication network equipment ElectroMagnetic Compatibility (EMC)». Оборудование eNodeB должно питаться напряжением –48В DC или 220В AC. Система электропитания должна быть укомплектована аккумуляторной батареей. Оборудование eNodeB должно быть оснащено средствами защиты от бросков напряжения и тока. Оборудование eNodeB должно быть оснащено средствами диагностики и автоматического обнаружения сбоев программных и аппаратных блоков. Оборудование eNodeB, поставляемое в наружнем исполнении, должно надежно работать в диапазоне температур -40 до +50°С с сохранением полной функциональности. Для надежности эксплуатации в оборудовании eNodeB должна быть предусмотрена защита от разрядов молний. Показатели надежности оборудования: должно быть обеспечено не менее 100000 часов наработки на отказ. Поставщик должен указать габаритные, установочные и монтажные размеры, а также массу на каждый тип поставляемого оборудования. 6.1.2. Назначения интерфейсов eNodeB 6.1.2.1. Оборудование eNodeB должно быть оснащено интерфейсами для контроля состояния внешних датчиков Сайта: 6.1.2.1.1. BBU: «сухие контакты» с возможностью выбора состояния (normally Open / normally Close) – не менее 8 независимых групп; 6.1.2.1.2. RRU: «сухие контакты» с возможностью выбора состояния (normally Open / normally Close) – не менее 2 независимых групп. 6.1.2.2. Оборудование eNodeB должно быть оснащено интерфейсами для управления внешними устройствами: 6.1.2.2.1. BBU: «сухие контакты» с возможностью выбора состояния (normally Open / normally Close) – не менее 4 независимых групп; 6.1.2.2.2. RRU: «сухие контакты» с возможностью выбора состояния (normally Open / normally Close) – не менее 2 независимых групп. 68 6.1.2.3. 6.1.2.3.1. 6.1.2.3.2. 6.1.2.3.3. 6.1.2.3.4. 6.1.2.3.5. 6.1.2.4. 6.1.2.5. 6.1.2.6. 6.1.2.7. 6.1.2.8. 6.1.2.9. 6.1.2.10. 6.1.2.11. 6.1.2.12. Оборудование eNodeB должно обеспечивать передачу аварийных сигналов на устройства более высокого уровня сообщений: от системы электропитания Сайта (прерывание энергоснабжения от первичной сети 220 В, пониженный / повышенный уровень напряжения батарей); от климатической системы Сайта (отключение системы, повышенная / пониженная температура аккумуляторной батареи, повышенная / пониженная температура оборудования, повышенная влажность / затопление); от системы охранно-пожарной сигнализации (несанкционированное проникновение на Сайт, несанкционированный доступ к RRU, задымление Сайта); от системы RET (контроль исправности); опционально: контроль исправности / состояние технологического освещения (в том числе – навигационных огней); Интерфейсы взаимодействия с системой более высокого уровня: SNMP, RS-232 / Telnet, Socket TCP/IP. Оборудование eNodeB должно обеспечивать поддержку протокола S1-MME согласно спецификации 3GPP TS 24.301 Оборудование eNodeB должно обеспечивать поддержку протокола S1-U согласно спецификации 3GPP TS 29.274 Оборудование eNodeB должно обеспечивать поддержку протокола X2 согласно спецификаций 3GPP TS 36.420 – 36.424. Базовая станция eNodeB потенциального поставщика должна поддерживать физический оптический интерфейс GE LX для S1/X2 и O&M Базовая станция eNodeB потенциального поставщика должна поддерживать технологию VLAN. Потенциальный поставщик должен указать возможные ограничения по использованию VLAN ID (0…4095) и указать количество возможных VLAN интерфейсов. Базовая станция eNodeB потенциального поставщика должна поддерживать технологию IPsec для защиты пользовательских и сигнальных данных согласно рекомендациям 3GPP. Базовая станция eNodeB потенциального поставщика должна поддерживать архитектуру безопасности согласно спецификации 3GPP для контрольного (-C), пользовательского (-U) и уровня управления (-M). Потенциальный поставщик должен указать типы кодирования/шифрования для интерфейсов S1, Uu, X2. 6.1.3. Требования к составу сервисов 6.1.3.1. На интерфейсах eNodeB должны быть реализованы следующие телекоммуникационные сервисы (отдельные VLAN): 6.1.3.1.1. S1-C – сервис для трафика контрольного уровня LTE интерфейса S1; 6.1.3.1.2. S1-U – сервис для трафика уровня данных LTE интерфейса S1; 6.1.3.1.3. X2-C – сервис для трафика контрольного уровня LTE интерфейса X2; 6.1.3.1.4. X2-U – сервис для трафика уровня данных LTE интерфейса X2; 6.1.3.1.5. MGMN – сервис для трафика управления устройствами уровня MNO (management); 6.1.3.1.6. SYNC – сервис для трафика синхронизации. 6.2. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К eNodeB 6.2.1. Технические требования к BBU eNodeB 6.2.1.1. Оборудование BBU должен, при необходимости обеспечивать работу eNodeB в стандартах GSM/GPRS/EDGE, WCDMA/HSUPA/HSDPA/HSPA+. 6.2.1.2. Потенциальный поставщик должен описать сервисную емкость базовой станции. 69 6.2.1.3. 6.2.1.4. 6.2.1.5. 6.2.1.6. Потенциальный поставщик должен предложить путь для увеличения пропускной способности eNodeB от начального до максимального значения и подробно описать связанные с этим необходимые физические и функциональные изменения. Потенциальный поставщик должен указать параметры типичных шагов наращивания емкостей и их состав. Каждый шаг должен быть пронумерован. Потенциальный поставщик должен описать политику расширения емкости BBU, основанную на программных лицензиях/ключах. Указать емкостные элементы под контролем программных лицензий и градацию, применяемую к ним. Потенциальный поставщик должен указать максимальное количество LTE ячеек поддерживаемых BBU, при условии, что каждый RRU обеспечивает полосу рабочих частот 20МГц и режим 2x2MIMO. 6.2.2. Технические требования к RRU eNodeB 6.2.2.1. Радиочастотный модуль должен поддерживать всю полосу частот предусмотренных стандартом LTE – 1,4 МГц, 3 МГц, 5 МГц, 10 МГц, 15 МГц и 20 МГц без необходимости замены/обновления/добавления аппаратного или программного обеспечения. 6.2.2.2. Двухмодовый режим 1800МГц GSM и 1800MГц LTE должен поддерживаться на одном RRU. Поставщик должен предоставить детальную информацию об условиях применения поставляемых RRU в таком режиме, включая аппаратные и лицензионные ограничения. 6.2.2.3. Двухмодовый режим RRU, который поддерживает 1800MHz GL(GSM+LTE) одновременно, должен быть коммерчески доступен к дате проведения Конкурса. 6.2.2.4. Потенциальный поставщик должен предоставить информацию о возможности одновременной поддержки радиочастотным модулем: 20МГц LTE и 5 МГц GSM в диапазоне частот 1800МГц. 6.2.2.5. Потенциальный поставщик должен указать минимальную защитную полосу необходимую между частотами при одновременном использовании GSM и LTE. 6.2.2.6. Потенциальный поставщик должен указать максимальную и минимальную конфигурацию eNodeB при совместном использовании различных технологий. 6.2.2.7. RRU eNodeB должен соответствовать требованиям по пыле- и влага-защищенности не хуже IP65, и не использовать для охлаждения электромеханических компонентов (вентиляторов). 6.2.2.8. Максимальное значение выходной мощности передатчика RRU должно составлять не менее 40 Вт на передатчик. Суммарное значение полезной выходной мощности (для всех используемых технологий и антенн), измеряемое на антенном порту, должно составлять не менее 40 Вт. Для конфигурации LTE 2x2 MIMO должен быть обеспечен режим 2х40 Вт. 6.2.2.9. Приемопередатчики RRU должны иметь встроенные датчики температуры, падающей и отраженной мощности для определения КСВ и должны генерировать соответствующие сигналы тревоги в системе мониторинга и управления при выходе параметров за установленные границы. 6.2.2.10. RRU должны поддерживать следующие виды модуляции: 6.2.2.10.1. DL: QPSK, 16-QAM, 64-QAM 6.2.2.10.2. UL: QPSK, 16-QAM и готовность поддержки на аппаратном уроне 64-QAM 6.2.2.11. Эффективность энергопотребления RRU (суммарная мощность на ВЧ портах / суммарная мощность потребления * 100% ) должна достигать не менее 20%. 6.2.2.12. RRU должны поддерживать контроль и наблюдение за внешним оборудованием (RET, TMA и т.д.). 6.2.2.13. eNodeB должен иметь возможность работать с различными типами RET и TMA от различных производителей. 6.2.2.14. Должен быть реализован протокол AISG 2.0 для RET контроля. 6.2.2.15. Все RRU должны иметь возможность монтирования на стене, трубе, столбе и решетке вышки. 70 6.2.3. Требования к производительности 6.2.3.1. Пропускная способность радиоканала LTE в направлении «к абоненту» должна быть обеспечена на уровне не ниже 150 Мбит/с на сектор. 6.2.3.2. Пропускная способность радиоканала LTE в направлении «от абонента» должна быть обеспечена на уровне не ниже 50 Мбит/с на сектор. 6.2.4. QoS 6.2.4.1. Базовая станция eNodeB потенциального поставщика должна поддерживать следующие функции QoS: 6.2.4.1.1. Поддержка min и max. bit rate; 6.2.4.1.2. Поддержка UE AMBR; 6.2.4.1.3. Поддержка Multiple EPS bearer, UE AMBR modification, GBR, дифференциация услуг (service differentiation); 6.2.4.2. Потенциальный поставщик должен обеспечить поддержку QoS для услуг и/или дифференциации пользователей в сети. 6.2.4.3. Потенциальный поставщик должен обеспечивать поддержку соответствующих транспортных механизмов: 6.2.4.3.1. Приоритезация трафика на уровне IP; 6.2.4.3.2. Приоритезация трафика в Ethernet; 6.2.4.3.3. Разделение трафика; 6.2.4.3.4. Управление формой трафика. 6.2.4.4. Для каждой из услуг в eUTRAN потенциальный поставщик должен: 6.2.4.4.1. Указать варианты возможных QoS/QC; 6.2.4.4.2. Указать какие значения поддерживаются для параметров QoS. 6.2.4.5. Базовая станция eNodeB потенциального поставщика должна поддерживать возможность использования маркировок Diffserv для обеспечения различных приоритетов scheduler eNodeB. 6.2.4.6. Базовая станция eNodeB потенциального поставщика должна поддерживать non-GBR QCIs. 6.2.4.7. Базовая станция eNodeB потенциального поставщика должна поддерживать GBR QCIs. 6.2.5. Технические требования к антенной системе 6.2.5.1. Антенная система eNodeB должна обеспечить функционирование трехсекторной базовой станции в режиме 2х2 MIMO. 6.2.5.2. В качестве антенн базовых станций должны использоваться двухдиапазонные панельные антенны производства KATHREIN/ANDREW с кросс-поляризацией ±45°, с количеством портов 4, перекрывающие рабочие диапазоны частот 790 - 960 / 1710 2180 МГц. 6.2.5.3. Конструкция должна обеспечивать возможность изменения угла наклона диаграммы направленности (ДН) антенн в горизонтальной плоскости. Поставляемые антенны должны обеспечить возможность комбинации механического и электронного способов изменения угла наклона. Последний - с применением систем дистанционного управления (RET). 6.2.5.4. В комплект поставки должны быть включены крепежная арматура, механизм механического наклона, блоки управления электрическим наклоном диаграммы направленности (при необходимости). В комплект поставки eNodeB должны быть включено оборудование и материалы, необходимые для монтажа системы RET. 6.2.5.5. Рекомендуемые технические характеристики антенн: 6.2.5.5.1. Конструкция: панельная, сдвоенная, с электронной регулировкой угла наклона ДН в горизонтальной плоскости; 6.2.5.5.2. Поляризация: кроссполярная ±45°; 71 6.2.5.5.3. 6.2.5.5.4. 6.2.5.5.5. 6.2.5.5.6. 6.2.5.5.7. 6.2.5.5.8. Диапазон рабочих частот: 790-960/1710-2180 МГц; Ширина диаграммы направленности в горизонтальной плоскости: 65°/65°; Усиление: 14,5/17,5dBi; Пределы регулировки угла наклона ДН: 0°-14°/0°-8°; Габаритные размеры (ДхШхГ, для справок): 1334х261х146 мм: Масса (для справок): 15,5 кг. 6.2.6. Требования к функциональности SON 6.2.6.1. Автоматическое планирование параметров радио. 6.2.6.2. Автоматическое планирование и настройка параметров S1-интерфейса. 6.2.6.3. eNodeB self-discovery (самообнаружение). 6.2.6.4. Аутентификация eNodeB. 6.2.6.5. Автоматическая установка и обновление программного обеспечения eNodeB. 6.2.6.6. Проверка состояния оборудования. 6.2.6.7. Проверка состояния сети. 6.2.6.8. Автоматическая настройка PCI (Physical Cell Identifier). 6.2.6.9. Intra-Freq ANR (Automatic Neighbor Relation). 6.2.6.10. Inter-Freq ANR. 6.2.6.11. Inter-RAT ANR . 6.2.6.12. Надежная оптимизация мобильности. 6.2.6.13. Динамическая балансировка нагрузки. 6.2.6.14. Оптимизация RACH (Random Access Channel). 6.2.6.15. Исправление ошибок. 6.2.6.16. Счетчики производительности и прямой отчетности KPI в режиме реального времени. 6.3. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ ЭЛЕКТРОПИТАНИЯ eNodeB 6.3.1. Требования к системам электропитания eNodeB Система питания постоянного тока должна: 6.3.1.1. Состоять из системы электропитания / преобразования напряжения переменного тока в напряжение постоянного тока типа AC-DC. 6.3.1.2. Иметь блок распределения переменного и постоянного тока, выпрямители и системный блок управления. 6.3.1.3. Обеспечивать достаточную выходную мощность с учетом дополнительной нагрузки 50Вт для оборудования Cell Site Gateway c 25% запасом и возможностью модульного расширения. 6.3.1.4. Продолжительно работать при напряжении трехфазной сети 340-440 В и однофазной сети 170-253 В. 6.3.1.5. Работать без риска повреждения в диапазоне трехфазного напряжения 310-460 В и однофазного напряжения 179-265 В, при частоте 47-63 Гц, при температуре от -10 до +50 °С. 6.3.1.6. Быть оборудована системой «мягкий» пуск, т.е. системой гашения всплесков коммутационных токов. 6.3.1.7. Обеспечивать автоматический запуск при появлении входного переменного напряжения независимо от уровня заряда/разряда аккумуляторных батарей. 6.3.1.8. Иметь выходное напряжение постоянного тока с буферным подключением батарей в режиме постоянного подзаряда, регулируемое в пределах 42-58 В и режима ускоренного заряда 54-56 В. 6.3.1.9. Иметь флуктуацию выходного напряжения не более ±60 мВ при изменении входного напряжения сети 360-440 В, при 10% и 100% нагрузке. 6.3.1.10. Обеспечивать работу блоков без риска повреждения при коротком замыкании на выходе и автоматически восстанавливать выходное напряжение при пропадании короткого замыкания. 72 6.3.1.11. Иметь стабильность выходного напряжения (изменение выходного напряжения менее 5% при изменении нагрузки от 10 до 90% и от 90% до 10% в период времени не более 10 мсек.). 6.3.1.12. Иметь двухступенчатый контроль уровня разряда батарей и автоматическое отключение батареи от нагрузки при низком напряжении батареи. 6.3.1.13. Иметь контроль заряда батарей и режим ускоренного заряда (программный заряд). 6.3.1.14. Иметь сигнализацию нормальной работы системы и аварийного состояния (местной, аудио и удаленной, через «сухие» контакты): 6.3.1.14.1. пропадание входной сети переменного тока по фазам; 6.3.1.14.2. авария выпрямителей; 6.3.1.14.3. отсутствие выпрямителей; 6.3.1.14.4. высокая температура; 6.3.1.14.5. низкое напряжение батареи; 6.3.1.14.6. отключение батарей по низкому напряжению. 6.3.1.15. Иметь класс защиты между входом и выходом системы, соответствующий требованиям VDE 0804 и IEC 0950; 6.3.1.16. Иметь электрическую изоляцию между вводом и корпусом и выходом и корпусом не менее 20 МОм при напряжении до 500 В; 6.3.1.17. Иметь электрическую прочность изоляции, соответствующую требованиям IEC 950, EN60950. 6.3.2. Требования к монтажному исполнению 6.3.2.1. Модульное исполнение блоков выпрямителей с резервирование по схеме не менее n+1. 6.3.2.2. Местное и дистанционное управление с возможностью интеграции в OSS. 6.3.2.3. Контрольная панель должна обслуживаются без отключения стойки питания. 6.3.2.4. Устройство управления и контроля должно быть оборудовано монитором с дисплеем для установки следующих параметров: 6.3.2.4.1. выходное напряжение; 6.3.2.4.2. емкость батарей; 6.3.2.4.3. режим заряда батарей (ускоренный и стандартный). 6.3.2.5. Контроль и отображение следующих параметров: 6.3.2.5.1. входное напряжение переменного тока по фазам; 6.3.2.5.2. выходное напряжение; 6.3.2.5.3. ток нагрузки; 6.3.2.5.4. ток по блокам; 6.3.2.5.5. температура блоков выпрямителей; 6.3.2.5.6. емкость в % при заряде батарей в каждой группе. 6.3.3. Технические требования к аккумуляторным батареям 6.3.3.1. Должны быть применены герметичные необслуживаемые аккумуляторные батареи с гелиевым электролитом со сроком службы не менее 7 лет. 6.3.3.2. Емкость аккумуляторных батарей должна обеспечивать бесперебойную работу оборудования Сайта в течение не менее 4 часа (при температуре окружающей среды 20°С). 6.3.3.3. Удовлетворять требованием по току и напряжению для обеспечения нормальной работы оборудования во время отключения входного напряжения 220/380 В. 6.3.3.4. В целях устойчивой работы системы и обслуживания должно быть не менее 2-х групп батарей. 6.3.3.5. Диапазон рабочих температур от -10°С до +50°С. 6.3.3.6. Доступ к монтажу батарей должен быть с лицевой стороны. 73 6.3.3.7. В случае внешнего исполнения (установка вне стойки питания) аккумуляторные батареи должны комплектоваться аккумуляторными шкафами/стеллажами и климатсистемой. 6.3.4. Общие требования 6.3.4.1. Сертификат соответствия Республики Казахстан на системы бесперебойного питания и батареи. 6.3.4.2. Инструкция по монтажу и эксплуатации. 6.3.4.3. Срок гарантии на оборудование не менее 24 месяцев. 6.3.4.4. Обеспечение пост гарантийным ремонтом. 6.4. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ОБОРУДОВАНИЮ РРЛ 6.4.1.1. Поставщик обязан поставить оборудование РРЛ для организации «последней мили» трансмиссии RAN. Кол. пролетов / комплектов РРЛ приведено в п.3. 6.4.1.2. Основные технические требования, условия эксплуатации, требования к поставляемым материалам – совпадают с аналогичными требованиями в отношении оборудования eNodeB. 6.4.1.3. Диапазон частот РРЛ – 28-42 ГГц. 6.4.1.4. Типоразмер антенн – 0,6 м и 0,3 м. 6.4.1.5. Конфигурация резерва 1+0. 6.4.1.6. Должна быть предусмотрена реализация механизмов адаптивной модуляции и автоматического управления мощностью передатчиков. 6.4.1.7. Оборудование РРЛ должно обеспечивать поддержку синхронизации согласно ІЕЕЕ 1588v2. 6.4.1.8. Должна быть обеспечена эффективная поддержка QoS (классификация трафика по полям DSCP, IP ToS в IP-пакетах, а также поддержка протокола IEEE 802.1p) 6.4.1.9. Пропускная способность от 300Мбит/с с возможностью расширения до 1Гбит/с. 6.4.1.10. Рабочие параметры предлагаемого оборудования должны гарантироваться при температуре окружающей среды от - 50°С до + 50°С. 6.4.1.11. Оборудование РРЛ должно поддерживать физический оптический интерфейс GE LX для S1/X2 и O&M. 6.4.1.12. Оборудование РРЛ должно поддерживать технологию VLAN. Потенциальный поставщик должен указать возможные ограничения по использованию VLAN ID (0…4095) и указать количество возможных VLAN интерфейсов. 6.4.1.13. На интерфейсах оборудования РРЛ в сторону eNodeB должны быть реализованы следующие телекоммуникационные сервисы (отдельные VLAN): 6.4.1.13.1. S1-C – сервис для трафика контрольного уровня LTE интерфейса S1; 6.4.1.13.2. S1-U – сервис для трафика уровня данных LTE интерфейса S1; 6.4.1.13.3. X2-C – сервис для трафика контрольного уровня LTE интерфейса X2; 6.4.1.13.4. X2-U – сервис для трафика уровня данных LTE интерфейса X2; 6.4.1.13.5. MGMN – сервис для трафика управления устройствами уровня MNO (management); 6.4.1.13.6. SYNC – сервис для трафика синхронизации. 6.4.1.14. Должна быть обеспечена возможность организации различной топологии РРЛ: «цепочка», «каскад», «звезда». 6.4.1.15. Должна быть предусмотрена возможность удаленного управления оборудованием РРЛ, сбора и хранения информации об аварийных состояниях оборудования посредством отдельной системы управления, а также возможность интегрирования этой системы с системами управления и обработки статистической информации сети LTE. 6.4.1.16. Требования к поставляемым материалам и услугам – совпадают с аналогичными требованиями к оборудованию eNodeB. 74 6.4.1.17. Специальное требование: компоненты оборудования РРЛ должны интегрироваться в монтажное пространство шкафа / контейнера. Исключение – компоненты / блоки, устанавливаемые в непосредственной близости от антенн (интегрируемые с антеннами). 6.4.1.18. Требования к услугам в отношении к поставляемому оборудованию РРЛ – совпадают с аналогичными требованиями к оборудованию eNodeB. Дополнительные требования: 6.4.1.18.1. поставщик обязан провести номинальное планирование сети РРЛ (топология, частотное планирование, энергетический баланс, показатели готовности); 6.4.1.18.2. поставщик обязан провести номинальное планирование индексации, IP-адресации и маршрутизации (в том числе – резервной маршрутизации); 6.4.1.18.3. поставщик обязан провести планирование утилизации портовой и канальной емкости; 6.4.1.18.4. поставщик обязан провести номинальное проектирование системы управления РРЛ (включая аспекты интегрирования с системой управления сетью (OSS) LTE). 6.5. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ШКАФАМ / КОНТЕЙНЕРАМ 6.5.1. Общие требования к контейнерам 6.5.1.1. Шкафы/контейнеры предназначены для размещения оборудования eNodeB системы электропитания, аккумуляторных батарей и оборудования транспортной сети. 6.5.1.2. Шкафы/контейнеры должны поставляться в вандалозащищенном исполнении, обеспечивающим защиту от воздействий окружающей среды уровня IP65. Внутренняя отделка шкафов/контейнеров должна быть выполнена из негорючих материалов, и соответствовать требованиям международных стандартов. 6.5.1.3. В состав шкафа / контейнера должны быть включены автоматическая система обеспечения климатического режима (на основе технологии FreeCooling) и вентиляции, система охранно-пожарной сигнализации, система распределения и защиты цепей энергоснабжения оборудования, система местного освещения и заземления. 6.5.1.4. Шкаф / контейнер должен быть оснащен стандартными конструктивными элементами для установки основного и дополнительного оборудования eNodeB, главной шиной заземления оборудования, а также точкой подключения к контуру заземления объекта. 6.5.1.5. Теплоизоляция не должна терять своих качеств на протяжении всего срока службы, не должна поддерживать горение, подвергаться гниению и усадке. 6.5.1.6. Диапазон рабочих температур, поддерживаемый системой обеспечения климатического режима: 6.5.1.6.1. от +5 °С до +30 °С для отсека установки аккумуляторных батарей; 6.5.1.6.2. от -10 °С до +50 °С для остального объема шкафа / контейнера. 6.5.1.7. Электроснабжение системы обеспечения климатического режима и вентиляции должно быть организовано от системы электропитания Сайта. Должна быть предусмотрена возможность программирования параметров системы для различных режимов эксплуатации, определяемых: сезоном и временем суток, нагрузкой основного и дополнительного оборудования, режимом энергоснабжения Сайта (штатный или аварийный) и т.д.. 6.5.1.8. Доступ во внутреннее пространство шкафа / контейнера для целей монтажа, настройки и обслуживания оборудования должен обеспечиваться через минимальное кол. проемов, оборудованных дверями / люками. Двери / люки должны быть оснащены элементами герметизации и замками с индексом секретности не ниже 1:1 000 000. 6.5.1.9. Конструкция шкафа/контейнера должен обладать высокой устойчивостью к взлому, и жесткостью, обеспечивающую работоспособность замков дверей / люков и герметичность внутреннего объема при установке шкафа / контейнера на монтажную поверхность с уклонами и отклонениями от плоскостности до 5°С. 75 6.5.1.10. Шкаф/контейнер обеспечивать достаточно свободного пространства для размещения оборудования eNodeB и дополнительного оборудования (транспортной сети и РРЛ). 6.5.1.11. Шкаф/контейнер должен поставляться в состоянии заводской готовности – без необходимости какой-либо доработки на Сайте. Габаритные размеры должны укладываться в размеры (ШхГхВ) 1000х1000х2200 мм с допустимым отклонением в пределах +10%. В конструкции должна быть предусмотрена возможность агрегации нескольких шкафов / контейнеров в моноблок; в том числе – с применением объединительной / разгрузочной монтажной рамы. 6.5.1.12. В конструкции шкафа/контейнера должна быть обеспечена возможность ввода внешних кабельных линий через окна, расположенные в верхней части шкафа. Допускается наличие дополнительного ввода – снизу, в зоне, не выходящей за пределы габарита. Кабельные вводы должны герметизироваться без применения одноразовых герметизирующих материалов. 6.5.2. Технические характеристики 6.5.2.1. Условия эксплуатации от - 50°С до +50°С. Шкаф/контейнер должен обеспечивать заданные условия эксплуатации размещенного внутри оборудования для указанного диапазона температур в условиях прямого воздействия солнечного излучения и атмосферных осадков. 6.5.2.2. Относительная влажность воздуха до 100% при +30°С. 6.5.2.3. Степень огнестойкости III A. 6.5.2.4. Максимальная нагрузка: 6.5.2.4.1. на пол 1500 кг/м2; 6.5.2.4.2. на крышу 250 кг/м2; 6.5.2.4.3. на стены 350 кг/м2; 6.5.2.5. Гарантийный срок эксплуатации 2 года 6.5.2.6. Срок эксплуатации не менее 25 лет 6.6. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К МЕТАЛЛОКОНСТРУКЦИЯМ И МАТЕРИАЛАМ 6.6.1.1. Номенклатура и количество поставляемых материалов должны обеспечить монтаж оборудования Сайта в соответствии с требованиями Поставщика. До начала поставки Поставщик обязан предоставить детальное описание применяемых материалов, крепежных изделий, монтажных комплектов и т.п. 6.6.1.2. Поставляемые металлоконструкции должны иметь гальваническое антикоррозийное покрытие. 6.6.1.3. Поставляемые кабельные материалы должны сохранять физические параметры в условиях воздействия климатических факторов и прямого солнечного излучения. 6.6.1.4. Для организации фидерных линий должны применяться радиочастотные коаксиальные кабели; конструктивные элементы таких кабелей должны быть изготовлены из электротехнической меди. 6.6.1.5. Выбор конструктивных решений, а также способы монтажа оптических кабелей связи BBU-RRU должны обеспечивать надежность стыков разъемных соединений и безотказную эксплуатацию в течение всего срока эксплуатации. 6.6.1.6. Поставщик обязан обеспечить комплектование Сайтов мерными отрезками оптического кабеля связи BBU-RRU, не допуская при монтаже излишков более 15% от длины кабельной линии. Номенклатура размерных групп (длин) оптического кабеля определяется Поставщиком по результатам обследования объектов установки eNodeB и должна быть согласована с Заказчиком. 6.6.1.7. Должна быть предусмотрена поставка оптического кабеля связи BBU-RRU всех применяемых размерных групп в составе ЗИП. Кол. кабеля, поставляемого в ЗИП, должно составлять не менее 10% от общего количества, использованного при монтаже. 76 6.6.1.8. Должно быть предусмотрено применение технических решений, обеспечивающих защиту кабельных линий от механических повреждений, в том числе с использованием защитных коробов, гофрированных труб и рукавов. 77 7. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К OSS 7.1. ТРЕБОВАНИЯ К СИСТЕМЕ OSS Система OSS (operation support system) является системой мониторинга и управления системой сети стандарта LTE. 7.1.1. Общие требования к системе OSS 7.1.1.1. Система должна иметь возможность использования протокола SNMP для управления и сбора статистики с элементами сети LTE; 7.1.1.2. Система должна иметь возможность интеграции с вышестоящими системами управления и мониторинга с целью передачи потоков аварийных и информационных сообщений посредством протокола SNMP, RS-232 или Socket TCP/IP; 7.1.1.3. Система должна иметь WEB интерфейс для управления устройствами; 7.1.1.4. Система должна позволять централизовано обновлять программное обеспечения на оборудовании; 7.1.1.5. Система должна принимать сообщения об ошибках; 7.1.1.6. Система должна генерировать отчеты; 7.1.1.7. Система должна управлять уровнем доступа каждого отдельного оператора (группы) для каждого отдельного типа устройств и региона; 7.1.1.8. Система должна управлять предоставляемыми сервисами на основе профилей клиентов; 7.1.1.9. Поставщик должен предоставить полное описание интерфейса, формат выдаваемых через него аварийных сообщений, необходимые файлы настроек (MIB-файлы); 7.1.1.10. Поставщик должен представить подробное описание аварийных сигналов на русском и английском языках; 7.1.1.11. Обеспечивать возможность мониторинга состояния, отслеживание неисправностей (алармов) элементов сети в реальном режиме времени. Иметь доступный и наглядный графический интерфейс; 7.1.1.12. Система должна обеспечивать возможность управления всеми элементами сети в реальном режиме времени с использованием как командной строки, так и графического интерфейса; 7.1.1.13. Система должна иметь в своем составе не менее 2-х рабочих мест с возможностью расширения, в том числе – разнесенных географически; 7.1.1.14. Поставка должна включать в себя лицензии не менее чем на 10 одновременно подключенных рабочих мест. 7.1.1.15. Поставщик обязан предоставить на отдельных носителях установочное ПО для клиента системы управления. 7.1.1.16. Клиентское ПО должно иметь возможно установки на PC под управлением Windows 7 и XP. 7.1.1.17. Система должна иметь многоуровневую систему администрирования уровней доступа к системе управления; 7.1.1.18. Система должна обеспечивать сохранение статистической информации по работе сети и лог-файлов о вносимых изменениях за период не менее чем 3 месяца; 7.1.1.19. Система должна иметь в своем составе инструментарий для сбора, обработки и анализа статистической информации о качественных показателях работы сети с представлением результатов как в табличном, так и в графическом виде; 7.1.1.20. Система должна разрешать локальный и дистанционный доступ к административным функциям; 7.1.1.21. Система OSS должна содержать как минимум следующие подсистемы: 7.1.1.21.1. Fault Manager. (Подсистема сбора аварий с элементов сети). 7.1.1.21.2. System status monitor. (Подсистема мониторинга состояния всех элементов сети и критичных интерфейсов). 78 7.1.1.21.3. Statistic collection system. (Подсистема сбора и хранения исходных статистических данных со всех элементов сети). 7.1.1.21.4. Performance reports system. (Подсистема генерации отчетов по работе оборудования). 7.1.1.21.5. Self-Organizing Networks (SON) подсистема самонастройки радиосети. 7.1.1.21.6. Inventory management (Подсистема управления и контроля перемещения материалов и оборудования (инвентаризации)) 7.1.1.21.7. Trouble Ticketing and Work Force management (Система создания, учета и управления Техподдержкой) 7.1.1.22. Система должна обеспечивать мониторинг состояния всех элементов сети в отдельности в реальном времени. 7.1.1.23. Система должна обеспечивать возможность оператору блокировать/разблокировать радиоресурсы на каждой eNodeB с отображением текущего статуса. 7.1.1.24. Поставщик обязан предоставить описание всех счетчиков статистики генерируемых оборудованием. 7.1.1.25. Система должна иметь возможность обрабатывать и хранить все счетчики статистики генерируемые оборудованием. 7.1.1.26. Для хранения статистических данных должна использоваться база данных с поддержкой интерфейса SQL. 7.1.1.27. Поставка должна включать централизованную систему управления для Казахстана с возможностью обслуживания в дальнейшем сетей LTE/GSM/HSPA рассчитанных до 4 млн абонентов. 7.2. ИДЕОЛОГИЯ ПОСТРОЕНИЯ СИСТЕМЫ OSS Для обеспечения задач мониторинга вся сеть должна быть разделена на 3 домена: 7.2.1. домен Radio Access Network (RAN) 7.2.2. домен Mobile Backhaul Network (MBN) 7.2.3. домен Evolved Packet Core (EPC) Данное разделение позволяет установить четкие з оны ответственности, не нарушая полноты функций управления сетью. 79 Inventory management (Подсистема управеления и контроля перемещения материалов и оборудования (инвентаризации)) Trouble Ticketing and Work Force management (Система создания, учета и управления Техподдержкой) 7.2.4. Система управления для оборудования RAN 7.2.4.1. Систему управления должна определять тип устройств, его параметры и конфигурацию. 7.2.4.2. Пользователь должен иметь возможность получить через графический интерфейс системы данные о состоянии устройства и его модулей. 7.2.4.3. Должна поддерживаться возможность настройки параметров оборудования через графический интерфейс системы управления. 7.2.4.4. Система управления должна поддерживать возможность удаленного мониторинга оборудования базовых станций путем получения аварийных сообщений и периодического опроса устройств. 7.2.4.5. Аварийные события должны быть доступны оператору через графический интерфейс. 7.2.4.6. Должна быть возможность подтверждать и удалять события оператором. 7.2.4.7. Должна поддерживаться возможность пересылки аварийных событий, полученных с оборудования и сгенерированных системой на другие системы управления посредством протокола SNMP. 7.2.4.8. Система управления должна поддерживать возможность сбора данных по производительности оборудования. 7.2.4.9. По данным по производительности должна быть возможность построения отчетов в графическом интерфейсе системы управления и выгрузки данных во внешний файл в формате CSV. 7.2.4.10. Система управления должна поддерживать возможность удаленного обновления программного обеспечения оборудования. 7.2.4.11. Должна поддерживаться возможность резервного копирования и восстановления конфигурации. 7.2.4.12. Система управления должна поддерживать функциональность SON. 80 7.2.5. Система управления для оборудования EPC 7.2.5.1. Система управления должна поддерживать возможность удаленного мониторинга оборудования путем получения аварийных событий и периодического опроса оборудования 7.2.5.2. Аварийные события должны быть доступны оператору через графический интерфейс. 7.2.5.3. Должна быть возможность подтверждать и удалять события оператором. 7.2.5.4. Система управления должна предоставлять отчетность по аварийным событиям в разрезе типов и количества за определенные временные интервалы 7.2.5.5. Должна быть возможность запуска скриптов по факту получения аварийного события 7.2.5.6. Для интеграции системы управления с другими системами должны поддерживаться стандарты: 7.2.5.6.1. TS 32.111-3, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Fault Management; Part 3: Alarm Integration Reference Point (IRP): Common Object Request Broker Architecture (CORBA) Solution Set (SS) 7.2.5.6.2. TS 32.303, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Configuration Management (CM); Notification Integration Reference Point (IRP): Common Object Request Broker Architecture (CORBA) Solution Set (SS) 7.2.5.7. Система управления должна предоставлять возможность настройки устройства через графический интерфейс 7.2.5.8. Должны поддерживаться следующие функции: 7.2.5.8.1. Добавление, модификация и изменение параметров доступа к оборудованию 7.2.5.8.2. Настройка параметров уровня шасси, модулей и портов 7.2.5.8.3. Добавление, удаление и изменение контекстов 7.2.5.8.4. Настройка параметров протоколов внутри контекстов, таких как серверы AAA, GGSN/MME/S-GW/P-GW, IP access list, интерфейсы IP, маршруты IP, IP адреса, параметры RADIUS, PPP, клиентов 7.2.5.9. Система управления должна поддерживаться возможность обновления программного обеспечения оборудования 7.2.5.10. Для обновления программного обеспечения через графический интерфейс системы управления должны быть доступны следующие функции: 7.2.5.10.1. Настройка параметров для загрузки устройства 7.2.5.10.2. Пересылка файла конфигурации и образа ПО на устройство и из него 7.2.5.10.3. Установка образа и контроль ошибок 7.2.5.11. Система управления должна поддерживать возможность резервного копирования файлов конфигурации 7.2.5.12. Система управления должна поддерживать возможность сбора данных по производительности оборудования и отображения этих данных в виде отчетов 7.2.5.13. Должна быть возможность экспорта параметров по производительности в формате, определенным стандартами 3GPP. 7.2.5.14. Система управления должна предоставлять гибкие возможности по назначению прав доступа пользователей. 7.2.5.15. Должна быть возможность назначения следующих прав пользователям: 7.2.5.15.1. Оператор. Возможность выполнения ограниченного набора команд для контроля работоспособности и диагностики оборудования 7.2.5.15.2. Администратор. Возможность выполнения всех команд на оборудовании. 7.2.6. Система управления должна обеспечивать 7.2.6.1. Интеграцию с существующей у Заказчика Системой Управления Сетями Телекоммуникаций посредством передачи потоков аварийных и информационных сообщений с использованием интерфейса SNMP. 81 7.2.7. Общие требования ко всем интерфейсам: 7.2.7.1. Все принимаемые сообщения должны содержать: 7.2.7.1.1. Физический и/или логический адрес оборудования, на котором произошла неисправность; 7.2.7.1.2. Идентификатор или внутренний номер репортажа; 7.2.7.1.3. Тип репортажа (проблема/разрешение/информация); 7.2.7.1.4. Категория срочности устранения неисправности (critical/minor/major, и т.п.); 7.2.7.1.5. Дата и время возникновения неисправности; 7.2.7.1.6. Другая дополнительная информация, которую технический персонал может использовать для локализации и устранения неисправности оборудования. 7.2.7.2. Эксплуатационная документация на поставляемое оборудование должна содержать перечни аварийных и информационных сообщений, включающие в себя описание формата сообщений, идентификаторы (уникальные ключевые слова) сообщений, и их описание на английском и русском языках. 7.2.8. Требования к интерфейсу SNMP: 7.2.8.1. Сообщения должны передаваться в следующих форматах: 7.2.8.1.1. SNMP V1 traps, V2c traps, and V3 traps; 7.2.8.1.2. SNMP V2c and V3 informs. 7.2.8.2. Эксплуатационная документация на поставляемое оборудование должна содержать: 7.2.8.2.1. Версию используемого протокола; 7.2.8.2.2. Набор всех необходимых MIB файлов, соответствующий оборудованию, включая все вышестоящие MIB; 7.2.8.2.3. Описание Trap’ов и Inform’ов; 7.2.8.2.4. Описание и формат значений передаваемых OID’ов. 82 8. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СОРМ 8.1.1. С целью обеспечения проведения СОРМ, оборудование EPC должно поддерживать возможность передачи необходимой информации в сторону Центра Мониторинга Оператора Связи. 8.1.1.1. Передача информации должна осуществляться посредствам: 8.1.1.1.1. зеркалирования трафика абонентов сети в объеме 100%; 8.1.1.1.2. зеркалирования трафика авторизации абонентов (DIAMETER) в объеме 100%; 8.1.1.2. и обеспечивать Центру Мониторинга: 8.1.1.2.1. получение сведений о переданных текстовых и графических документальных сообщениях; 8.1.1.2.2. получение статистических сведений об осуществленных соединениях абонентов с Интернет-ресурсами: 8.1.1.2.2.1. адреса обращения к Интернет-ресурсам в сети передачи данных; 8.1.1.2.2.2. идентификаторы Интернет – ресурса (URL, URI, доменное имя); 8.1.1.2.2.3. адреса переданного или полученного электронного сообщения; 8.1.1.2.2.4. адреса электронной почты почтового сообщения. 8.1.1.3. Зеркалируемый трафик абонентов должен содержать статистические сведения, отражающие типы сервисов (протоколы) используемые пользователем из следующих протоколов: 8.1.1.3.1. Протоколов передачи гипертекстовой информации и файлов: HTTP, FTP; 8.1.1.3.2. Протоколов передачи почтовых и новостных сообщений: SMTP, POP3, IMAP4, NNTP, RSS; 8.1.1.3.3. Протоколов систем обмена мгновенными сообщениями: ICQ, MSN Messenger, Yahoo Messenger, IRC, Mail.ru агент; 8.1.1.3.4. Протоколов Web-почты: Google Mail, Yahoo Mail, HotMail, Mail.ru, Yandex.ru, Rambler.ru, не использующих криптографическое шифрование, с сохранением информации аналогично протоколам SMTP и POP3; 8.1.1.3.5. протокола удаленного доступа Telnet; 8.1.1.3.6. протоколов сигнализации IP-телефонии H.323, SIP, Megaco/H.248, MGCP, IAX2, Skinny; 8.1.1.3.7. протоколов авторизации RADIUS, TACACS+, DIAMETER. 8.1.1.4. Оборудование EPC должно обеспечивать сбор и хранение следующей информации: 8.1.1.4.1. сведений о местоположении мобильных абонентов; 8.1.1.4.2. служебной информации об абонентах; 8.1.1.4.3. статистической информации о соединениях заданных абонентов, включая фазы установления соединений, их продолжительность, объем переданных сообщений; 8.1.1.4.4. статистической информации обо всех соединениях в сети; 8.1.1.4.5. лог-журнал сетевых трансляций (NAT). 8.1.1.5. Оборудование EPC должно обеспечивать перехват сообщений заданных абонентов в процессе осуществления соединений и передачи информационных сообщений: 8.1.1.5.1. Перехват сообщений осуществляется посредством зеркалирования трафика абонента, при задании идентификационных признаков абонентов (IMSI) . 8.1.1.5.2. Должен быть обеспечен интерфейс взаимодействия между Центром мониторинга и EPC, для передачи идентификационных признаков абонентов (IMSI), подлежащих перехвату. 8.1.1.5.3. Средства перехвата сообщений должны обеспечивать перехват сообщений пользователей услуг связи в количестве не менее 1% от общего количества пользователей услуг связи. Должен обеспечиваться одновременный перехват сообщений разных пользователей. 8.1.1.6. Весь зеркалированный трафик должен передаваться в сторону Центра Мониторинга через стандартные интерфейсы Gigabit Ethernet, 10 Gigabit Ethernet. 83 9. ОБЩИЕ ЭКСПЛУАТАЦИОННЫЕ ТРЕБОВАНИЯ 9.1. ТРЕБОВАНИЯ К НАДЕЖНОСТИ 9.1.1. Система должна обеспечивать надежную работу с проектным показателем безотказности оборудования не менее 99,999%. Поставщик должен предоставить данные по надежности поставляемого оборудования. 9.2. ТРЕБОВАНИЯ К ОБЕСПЕЧЕНИЮ ЗАПАСНЫМИ ЧАСТЯМИ 9.2.1. Поставщик должен гарантировать, что все заменяемые платы, модули, мелкие детали и прочие запасные части, требуемые для техобслуживания системы, будут поставляться на протяжении как минимум 10 лет с момента сдачи системы в эксплуатацию. 9.2.2. В поставку должны быть включены запасные части согласно номенклатурному перечню и в количестве, рекомендуемые Поставщиком для первых 2 лет эксплуатации системы после ее приемки. 9.2.3. Вышеуказанный перечень должен обеспечить Заказчику необходимый резерв запасных частей наибольшего спроса. 9.3. ТРЕБОВАНИЯ К ГАРАНТИЙНОМУ И ПОСТГАРАНТИЙНОМУ ОБСЛУЖИВАНИЮ 9.3.1. Потенциальный поставщик должен предоставить гарантию сроком не менее 24 месяца на всё поставляемое оборудование и программное обеспечение (ПО) с момента ввода его в эксплуатацию, включая оборудование третьих сторон. 9.3.2. Неисправное оборудование должно быть восстановлено и возвращено Поставщиком в течении 45 (сорока пяти) дней с момента получения оборудования на ремонт. 9.3.3. Потенциальный поставщик должен предоставить Заказчику услуги по технической поддержке на весь период эксплуатации Сети. 9.3.4. Техническая поддержка должна включать в себя поставку и ремонт оборудования, сопровождение ПО. 9.3.5. Потенциальный поставщик должен предоставить описание программ постгарантийной поддержки поставляемого оборудования и ПО максимального («золото»), альтернативного («серебро») и минимального («бронза») объема с указанием годовой стоимости соответствующего объема. 9.3.6. Стоимость годовой постгарантийной поддержки, оказываемой центром поддержки потенциального поставщика, для максимального уровня послегарантийной поддержки («золото»), не должна превышать 7% от стоимости поставляемого оборудования и ПО. 9.4. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ 9.4.1. Победитель конкурса обязан предоставить казахстанский сертификат соответствия, или провести процедуру сертификации в срок до 3-х (трех) месяцев после даты заключения договора за свой счет; 9.4.2. Победитель конкурса обязан предоставить полное описание на поставляемое оборудование; 9.4.3. Победитель конкурса обязан предоставить рабочий проект по монтажу: 9.4.3.1. базовых станций eNodeB RAN; 9.4.3.2. оборудования EPC; 9.4.3.3. оборудования управления и контроля сети. 9.4.4. Победитель конкурса обязан предоставить методику проведения приёмосдаточных испытаний сети и согласовать её с клиентом; 9.4.5. Победитель конкурса обязан предоставить проект сети который должен включать в себя: 9.4.5.1. Схему организации сети с учётом интеграции в сеть ПД, СОРМ и Биллинговой системой; 84 9.4.5.2. Радио-планирование сети; 9.4.5.3. Планирование сети РРЛ 9.4.6. Победитель тендера обязан предоставить эксплуатационную документацию, которая должна содержать следующее: 9.4.6.1. руководство для инженерного персонала 9.4.6.2. конфигурацию сети 9.4.6.3. перечни аварийных и информационных сообщений, включающий в себя описание формата сообщений, идентификаторы (уникальные ключевые слова) сообщений, и их описание на английском и русском языках. 9.4.6.4. при использовании SNMP - полный перечень MIBs, описание MIBs, описание Trap и OID, формат значений Trap и OID; 9.4.6.5. при использовании RS-232 или Socket TCP/IP список команд инициализации режимов порта управления; 9.4.7. Техническая документация, состоящая из технических спецификаций (описания), руководства по эксплуатации (для пользователей) должны быть на русском языке. 9.4.8. По согласованию Сторон список технической документации может быть расширен. 9.5. ДОПОЛНИТЕЛЬНЫЕ ТРЕБОВАНИЯ 9.5.1. Обучение 9.5.1.1. Поставщик берет на себя все расходы по обучению инженерно-технического персонала в количестве не менее 16 (шестнадцати) человек, в авторизованных учебных центрах поставщика, с сертификацией инженерно-технического персонала Заказчика. Срок обучения должен оговариваться в контракте; 9.5.1.2. Поставщик должен предоставить содержание и график проведения обучения. Обучение обязательно должно содержать следующие темы: 9.5.1.2.1. архитектура сети LTE; 9.5.1.2.2. эксплуатация сети LTE и Управление Сетью (OSS); 9.5.1.2.3. DPI и PCRF, администрирование. 9.5.1.2.4. дизайн сети; 9.5.1.2.5. установка и обслуживание оборудования сети LTE. 9.5.1.3. Поставщик может предложить любые другие темы обучения, которые могут быть важными. 9.5.1.4. Поставщик должен подробно указать, что включает в себя цена за обучение. 85 10. ТРЕБОВАНИЯ К ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ И РЕМОНТУ 10.1.1. Поставщик должен обеспечивать поставку ЗИП. Цены на ЗИП не должны повышаться после заключения договора. 10.1.2. Поставщик должен иметь возможность предоставить Заказчику услуги по технической поддержке на весь период эксплуатации оборудования. 10.1.3. Поставщик должен обеспечить наличие на территории Республики Казахстан сертифицированного персонала, необходимого для организации как минимум первой линии поддержки для всего поставляемого оборудования. 10.1.4. Для устранения возникающих в оборудовании проблем, поставщик обязан 24 часа в сутки 7 дней в неделю предоставлять соответствующие услуги. Услуги по технической поддержке заключаются в полном устранении неисправности и приведении оборудования в состояние, имевшее место до аварии. 10.1.5. Техническая поддержка должна включать в себя поставку и ремонт оборудования, сопровождение программного обеспечения (устранение ошибок, загрузка новых версий ПО и др.), устранение аварий. 10.1.6. Услуги по технической поддержке классифицированы по степеням в зависимости от уровня серьезности проблемы: 10.1.6.1. Полная или частичная потеря трафика (ПРОБЛЕМА ПЕРВОЙ СТЕПЕНИ); 10.1.6.2. Опасность потери трафика (ПРОБЛЕМА ВТОРОЙ СТЕПЕНИ); 10.1.6.3. Проблемы, не влияющие на трафик (ПРОБЛЕМА ТРЕТЬЕЙ СТЕПЕНИ); 10.1.7. Нормативное время на устранение проблем: 10.1.7.1. Проблема первой степени – 4 часа; 10.1.7.2. Проблема второй степени – 48 часов; 10.1.7.3. Проблема третьей степени – 1 месяц. 10.1.8. Неисправное оборудование должно быть восстановлено и возвращено поставщиком в течение 45 дней со дня передачи оборудования от Заказчика Поставщику на ремонт. 10.1.9. Поставщик несет материальную ответственность за соблюдение времени устранения проблем. 86 11. ТАБЛИЦА СООТВЕТСТВИЯ ТЕХНИЧЕСКИМ ТРЕБОВАНИЯМ К ТЕНДЕРУ 11.1.1. Потенциальный поставщик должен заполнить в обязательном порядке таблицу соответствия техническим требованиям. При заполнении таблицы, необходимо соблюдать порядок, формат и содержание соответствующих пунктов технических требований. Ссылка на соответствующий пункт документации Потенциального поставщика приложенной к заявке на участие в настоящем тендере, обязательна. №№ Наименование Таблица 11.1 Таблица соответствия техническим требованиям Соответствие Ссылка на документацию. Примечание 11.1.2. Потенциальный поставщик должен заполнить таблицу для всех требований, содержащихся в технических требованиях. В случае отсутствия сведений, соответствующие технические требования будут считаться невыполненными потенциальным поставщиком. 11.1.3. В графе «№№» указывается номер пункта настоящих технических требований. 11.1.4. Сведения о соответствии настоящим техническим требованиям должны вноситься в формате: «полное соответствие» \ «частичное соответствие» \ «не соответствует». При неполном соответствии, необходимо в графе «Примечание» дать пояснение о не соответствии. 11.1.5. Пример заполнения таблицы соответствия: №№ Наименование Соответствие Ссылка на Примечание документацию. 5.1.2.12 EPC должна Частичное Документ Х, Раздел Х, Не поддерживает обеспечивать соответствие пункт Х.Х.Х. cdma2000 и WiMAX полную интеграцию с сетями не 3GPP: WiFi, cdma2000, WiMAX и другие … … … … … 11.2. Поставщик гарантирует, что поставляемое оборудование и программное обеспечение соответствует современным технологическим стандартам, является последними коммерчески доступными версиями аппаратных и программных релизов Поставщика. Поставщик гарантирует Заказчику, что поставляемое оборудование полностью соответствует критерию эффективных долгосрочных инвестиций Заказчика, в том числе: 11.2.1. Поставляемое Оборудование (аппаратный и программный комплекс) будет обеспечивать возможность внедрения нового разрабатываемого функционала и опций в течение минимум 5 лет (с даты Акта окончательной приемки) без необходимости дополнительных инвестиций в оборудование или замены/модернизации оборудования для поддержания данных функций; 11.2.2. Поставляемое Оборудование (аппаратный и программный комплекс) будет гарантировано развиваться, и совершенствоваться в течение минимум 5 лет в соответствии с представленными планами по развитию продуктовой линейки Поставщика (“Roadmaps”); 11.2.3. Поставляемое Оборудование в течение минимум 8 лет будет находиться в рамках доступности полнофункциональной технической поддержки Поставщика (включая замену и ремонт неисправных модулей и доступность запасных частей); 87 11.2.4. Функционал, изначально предоставленный Заказчику в рамках данного Договора, будет поддерживаться в течение минимум 5 лет в новых релизах аппаратного и программного обеспечения Поставщика (без необходимости дополнительной оплаты); 11.2.5. Емкость поставляемого оборудования полностью обеспечивает требования Заказчика, указанные в Технических требованиях без каких-либо ограничений и оговорок. Если одно или несколько указанных в п.11.2 условий не выполняется Поставщиком в течение указанного срока, Поставщик обязан предоставить за свой счет замену, расширение или модернизацию поставленного Оборудования, включая необходимые работы по внедрению, для обеспечения полного соответствия указанных требованиям. 11.3. Поставщик гарантирует, что все поставляемое Оборудование должно поставляться предоставляется Заказчику полностью лицензированным до своей максимальной физической емкости аппаратной части. Поставщик обязуется не устанавливать искусственные ограничения (программные или иные ключи активации), которые могут ограничивать возможность использования данного оборудования в рамках максимальной физической емкости. 11.4. Поставщик гарантирует предоставление всего комплекса базового и опционального функционала поставляемого Оборудования (включая разрабатываемый функционал в новых релизах программного обеспечения в течение 5 лет с момента подписания Акта окончательной приемки). Лицензирование емкости закупаемого оборудование производится в соответствии с Техническими требованиями Заказчика. 88 12. ТАБЛИЦА ЦЕН. 12.1. Потенциальный поставщик должен заполнить в обязательном порядке таблицу цен в формате, приведенном в Табл. 12.1. Таблица 12.1 № п.п. Наименование 1. Поставка оборудования и материалов, программного обеспечения, лицензий на условиях DAP/DDP (место установки), в том числе: 1.1. Оборудование, программное обеспечение и лицензии для организации пакетного ядра EPC в г.Алматы: MME (mobility management entity – узел управления мобильностью) UDC (user data convergence – конвергентная база данных) S-GW (serving gateway – обслуживающий шлюз) P-GW (packet data network gateway – пакетный шлюз) DPI (deep packet inspection – анализатор трафика) PCRF (policy and charging rules function – узел управления политик) OSS (operation support system – система управления сети) Ethernet коммутаторы (IP коммутаторы) FireWall(межсетевой экран) Маршрутизаторы EPC Система гарантированного электропитания DC и AC и аккумуляторные батареи Дизель-генератор Расходные материалы, необходимые для строительства пакетного ядра EPC Программное обеспечение и лицензии Запасные части, инструменты, принадлежности (ЗИП) в соответствии с рекомендациями производителя к каждому типу поставляемого оборудования Оборудование, программное обеспечение и лицензии, необходимые для строительства RAN в г. Алматы с заданными KPI: Комплект eNodeB, в том числе: Indoor исполнения Outdoor исполнения Запасные части, инструменты, принадлежности (ЗИП) Материалы, необходимые для строительства инфраструктуры для размещения базовых станций Оборудование, программное обеспечение и лицензии, необходимые для строительства RAN в г. Астана с заданными KPI: Комплект eNodeB, в том числе: Indoor исполнения Outdoor исполнения Запасные части, инструменты, принадлежности (ЗИП) в соответствии с 1.1.2. 1.1.3. 1.1.4. 1.1.5. 1.1.6. 1.1.7. 1.1.8. 1.1.9. 1.1.10. 1.1.11 1.1.12. 1.1.13. 1.1.14. 1.1.15. 1.1.16. 1.2. 1.2.1. 1.2.1.1. 1.2.1.2. 1.2.2. 1.2.3. 1.3. 1.3.1. 1.3.1.1. 1.3.1.2. 1.3.2. Ед.изм Кол -во компл. 1 компл. 1 компл. 1 компл. 1 компл. 1 компл. 1 компл. 1 компл. 1 компл. компл. компл. компл. 1 1 1 1 компл. компл. 1 1 компл. компл. 1 1 компл. компл. компл. компл. 201 48 153 компл. - компл. компл. компл. компл. 150 18 132 1 Цена за ед., тенге Стоим ость, тенге Краткое описание конфигураци и 89 1.3.3. 1.4. рекомендациями производителя к каждому типу поставляемого оборудования Материалы, необходимые для строительства инфраструктуры для размещения базовых станций Оборудование, программное обеспечение и лицензии, расходные материалы и ЗИП, необходимые для строительства транспортной сети РРЛ в гг. Алматы и Астана 2. Работы и услуги по строительству сети в гг. Алматы и Астана “под ключ”, в том числе: 2.1. Услуги по планированию, строительству, монтажу и пуско-наладке, интеграции, сдаче в эксплуатацию сети LTE в гг. Алматы и Астана “под ключ” Услуги по гарантийной поддержке поставляемого оборудования, программного обеспечения и лицензий Услуги по обучению персонала Заказчика Услуги по техническому сопровождению сети после запуска в эксплуатацию (baby seating) ИТОГО 2.2. 2.3. 2.4. компл. - компл. 90 услуга 1 услуга 1 услуга услуга 1 1 * При заполнении таблицы цен не допускается использование групповых или объемных скидок. Все цены должны указываться на условиях DAP/DDP Алматы, Астана. 12.2. Потенциальный поставщик должен предоставить детальную расшифровку стоимости каждого элемента сети до каждой отдельной платы/блока/пакета SW и единицы лицензии входящих в данную поставку. 12.3. Потенциальный поставщик должен предоставить техническое описание и детальную расшифровку стоимости каждого элемента сети для дальнейшего расширения, включая оборудование для построения сети 2G/3G. 12.4. Описание Ценового предложения должно быть дополнительно предоставлено в формате MS Excel. Все формулы и должны быть видны в excel документе. Все цены в закладках должны быть связаны с summary и другими расчетами. Страница SUMMARY должна представлять собой сведенную версию всех детальных цен и включенных в предложение. Каждый сервис/оборудование/программное обеспечение и функциональные возможности должны быть в деталях представлены на отдельных страницах и иметь линки на страницу Summary. Поставщик обязан добавлять и изменять страницы для обеспечения предоставления полного и детального ценового предложения. Поставщик обязан добавлять и указывать необходимые детали. Поставщик обязан добавлять и указывать необходимые формулы. 90 Приложение 1. К Техническому заданию. Перечень объектов, предлагаемых Заказчиком для предварительного планирования сети. Список сайтов в г. Алматы № ID объекта Адрес Широта Долгота 43,377297 76,991407 Высот а подвеса антенн 30 Примечание существующий, сайт Алтел. Объект КТ 1 13-Gorodok г.Алматы,13 в/г, д.6А, RSU-901, 2 AL001 г.Алматы, ул.Панфилова, 129 Телеграф 43,250975 76,944683 41 3 AL002 г.Алматы, мкр. Аксай-2 ул. Маречека, 36 АТС22-23-24 43,233466 76,832597 33 4 AL003 г.Алматы, ул. Байсебаева, 47а ПСК-368 43,350986 76,956772 29 5 AL004 г.Алматы пр. Достык 284. Бизнес Центр. 43,217796 76,964783 30 существующий, сайт Алтел 6 AL005 г.Алматы, ул. Гагарина, 270 АТС-48 43,208332 76,899445 35 существующий, сайт Алтел. Объект КТ 7 AL006 г.Алматы, ул.Ауэзова, 84 СЭС 43,236389 76,904999 30 существующий, сайт Алтел 8 AL007 г.Алматы, ул. Жургенева, 9 АТС-30 43,266109 76,955833 18 существующий, сайт Алтел. Объект КТ 9 AL008 г.Алматы, ул. Фурманова, 240а АТС-75 43,230232 76,952175 35 существующий, сайт Алтел. Объект КТ 10 AL009 г.Алматы, ул. Маметова, 76а 43,266098 76,932810 31 существующий, сайт Алтел 11 AL010 г.Алматы, ул. Желтоксан 175 43,238739 76,940163 32 существующий, сайт Алтел 12 AL011 г.Алматы, ул. Сатпаева, 90 АПСК АДК 43,233055 76,877502 38 существующий, сайт Алтел 13 AL012 г.Алматы, пр. Рыскулова, 95 Мастер Маркет 43,275528 76,893578 28 существующий, сайт Алтел 14 AL013 г.Алматы, ул. Туркебаева, 92. Торг. Дом Асыл 43,249817 76,878998 21 существующий, сайт Алтел 15 AL014 г.Алматы, ур. Медео, т/б Чимбулак, Гостиница 43,128478 77,082159 22 существующий, сайт Алтел 16 AL015 г.Алматы, ул. Тимирязева, 42 RAMSTOR Галарея 43,224722 76,910853 18 существующий, сайт Алтел 17 AL018 г.Алматы, совхоз Алатау, СМКС Орбита 43,188437 76,878855 31 существующий, сайт Алтел. Объект КТ 18 AL019 г.Алматы, Аэропорт, гостиница Ак-Сункар 43,345016 77,011250 20 существующий, сайт Алтел 19 AL020 г.Алматы, ул. Казыбаева, 286 (бывш. Авангардная) 43,309441 76,919805 33 существующий, сайт Алтел 20 AL021 г.Алматы, пр. Достык, 114 Дворец Школьников 43,237499 76,958054 26 существующий, сайт Алтел 21 AL022 г.Алматы, ул. Жумалиева, 108 (АТС-68) 43,251384 76,913592 18 22 AL023 г.Алматы, ул. Жарокова 191/189 43,230622 76,900210 19 23 AL024 Алматинская область, п. Каменка, сан. Алатау 43,196656 76,812807 33 существующий, сайт Алтел 24 AL025 г.Алматы, Алмаарасан, Плотина 43,136300 76,904547 16 существующий, сайт Алтел 25 AL026 г.Алматы, пр. Суюнбая 211, з-од Иссыкские вина 43,314958 76,956932 21 существующий, сайт Алтел 26 AL028 г.Алматы, Джандосова 59, Академия статистики 43,213100 76,869353 21 существующий, сайт Алтел 27 AL029 г.Алматы, ул. Домостроительная 83, Дом студента 43,227023 76,846106 31 существующий, сайт Алтел 28 AL030 г.Алматы, ул. Калинина 17А, ОАО Алматы, ОблТяжСтрой.(ГРЭС) 43,436547 77,021860 33 существующий, сайт Алтел 29 AL033 г.Алматы, Медеу, Плотина 43,151606 77,064476 7 существующий, сайт Алтел 30 AL034 г.Алматы, пр. Рыскулова, 72 43,284550 76,921844 20 существующий, сайт Алтел 31 AL035 г.Алматы, Ауэзова 3, АО "Карагай" 43,256322 76,895460 35 существующий, сайт Алтел 32 AL037 г.Алматы, пр. Доcтык 38 43,251902 76,956951 35 существующий, сайт Алтел 33 AL038 г.Алматы, ул. Тулебаева, 38 АО Жетису 43,264721 76,947777 23 существующий, сайт Алтел 34 AL039 г.Алматы, ул. Жамбыла, 190, АТС42/43 43,244551 76,900522 18 существующий, сайт Алтел. Объект КТ 35 AL040 г.Алматы, ул. Казанская, 34 43,274990 76,979178 12 существующий, сайт Алтел 36 AL041 г.Алматы, ул. Богенбай батыра 152, Казпочта 43,251945 76,933609 23 существующий, сайт Алтел 37 AL042 г.Алматы, пр. Абая,143 АО "Баспалар Уйi" г.Алматы, ул. Радостовца 152/6, ТОО НИИ Строй.Проект г.Алматы, пр. Достык, 105, гост. Премьер-Алатау 43,239291 76,893249 22 существующий, сайт Алтел 43,228592 76,894202 18 существующий, сайт Алтел 43,225528 76,960842 16 существующий, сайт Алтел 38 AL043 39 AL044 существующий, сайт Алтел. Объект КТ существующий, сайт Алтел. Объект КТ существующий, сайт Алтел. Объект КТ существующий, сайт Алтел. Объект КТ существующий, сайт Алтел. Объект КТ 91 40 AL046 г.Алматы, пр. Райымбека, 417а ОАО "Каздорпроект" 43,252222 76,855556 25 существующий, сайт Алтел 41 AL047 г.Алматы, ул. Утепова 19 а 43,219646 76,895303 24 существующий, сайт Алтел 42 AL048 г.Алматы, ул. Курмангазы 61 А 43,244599 76,941825 25 существующий, сайт Алтел 43 AL049 г.Алматы, рынок "Батыр" 43,289535 76,891839 13 существующий, сайт Алтел 44 AL050 г.Алматы, мкр. Баянаул, 57А Car City 43,238516 76,822361 16 существующий, сайт Алтел 45 AL051 г.Алматы, ул. Кунаева, 142 43,246975 76,951783 25 существующий, сайт Алтел 46 AL052 г.Алматы, ул. Розыбакиева, 247 (Мега Центр) 43,201809 76,892471 19 существующий, сайт Алтел 47 AL053 г.Алматы, ул. З.Шашкина, 14а Общежитие АЭИС 43,223922 76,931955 17 существующий, сайт Алтел 48 AL054 г.Алматы, мкр. Коктем 2, 19Аб АЛСИ 43,229916 76,921028 30 существующий, сайт Алтел 49 AL055 г.Алматы, ул. Масанчи, 88 Общежитие №4 КазЖДИ 43,243889 76,930832 19 существующий, сайт Алтел 50 AL056 г.Алматы, пр. Абая, 48. Центральный стадион 43,237746 76,920849 19 существующий, сайт Алтел 51 AL057 г.Алматы, пр. Абылай хана 60 43,263249 76,940800 30 существующий, сайт Алтел 52 AL058 г.Алматы, ул. Толеби 101, уг. Байтурсынова 43,253994 76,925224 52 существующий, сайт Алтел 53 AL059 г.Алматы, мкр. Мамыр, ул. Центральная, 8г ФХК "Енбек" 43,203795 76,849482 14 существующий, сайт Алтел 54 AL060 г.Алматы, ул. Зогре 18, ТОО "Алматы Логистик Центр" 43,337372 76,959026 25 существующий, сайт Алтел 55 AL061 г.Алматы, пр. Рыскулова, 53 Компания "Шабыт" 43,291543 76,932176 12 существующий, сайт Алтел 56 AL062 г.Алматы, пр. Аль-Фараби, 75а Институт почвоведения 43,209722 76,912778 26 существующий, сайт Алтел 57 AL063 г.Алматы, ул. Мустафина, 5а кинотеатр Байконур 43,199819 76,879332 15 существующий, сайт Алтел 58 AL064 Алматинскя область, п. Калкаман, ул. Ауэзова, 4 горбольница 43,232216 76,800050 26 существующий, сайт Алтел 59 AL065 г.Алматы, ул. Ибрагимова,1 43,347270 77,154469 65 существующий, сайт Алтел 60 AL066 г.Алматы, ул. Муратбаева, 23 институт Дарын 43,264883 76,916263 19 существующий, сайт Алтел 61 AL067 г.Алматы, ул. Казыбек-Би 30 43,256668 76,952499 31 существующий, сайт Алтел 62 AL069 г.Алматы, ул. Майлина, 77 43,341859 76,984983 31 существующий, сайт Алтел 63 AL070 Алматинская область, с. Алатау, ул. Горького, 64. 43,186010 76,898849 17 существующий, сайт Алтел 64 AL071 г.Алматы, 12 мкр. д.15а 43,221390 76,860832 20 существующий, сайт Алтел 65 AL072 г.Алматы, Горный Гигант, ул. Шукшина, 71 43,217117 76,941311 27 существующий, сайт Алтел 66 AL073 г.Алматы, пр. Суюнбая, 143 a, автосалон "Persia Motors" 43,285791 76,948515 17 существующий, сайт Алтел 67 AL074 г.Алматы, ул. Кожамкулова 204 43,248215 76,917983 19 существующий, сайт Алтел 68 AL075 г.Алматы, пр. Раимбека 165 43,270000 76,934723 20 существующий, сайт Алтел 69 AL076 г.Алматы, ул. Горная, 500 43,176998 77,015531 25 существующий, сайт Алтел 70 AL077 г.Алматы, ул. Тимирязева 15б 43,230550 76,932795 19 существующий, сайт Алтел 43,328746 76,898431 21 существующий, сайт Алтел 43,355503 76,859972 29 существующий, сайт Алтел 71 AL079 72 AL081 г.Алматы, мкр. Ужет, 6-й градокомплекс, участок 302 п. Боралдай, ул. Бостанова 2, сахарный завод, АО "Алматы канты" 73 AL082 г.Алматы, ул. Отеген Батыра 11а, уг. ул. Толе 296 43,244296 76,855020 17 существующий, сайт Алтел 74 AL085 г.Алматы, Ремизовка, ул. Альфараби 118, КТР 43,209040 76,925105 32 существующий, сайт Алтел 75 AL087 г.Алматы, ул. Азербаева 130, ТОО "Lemonadoff Food" 43,254808 76,979177 16 существующий, сайт Алтел 76 AL089 г.Алматы, мкр. Хан Тенгри, котельная 43,168595 76,874932 32 существующий, сайт Алтел 77 AL091 г.Алматы, мкр-н, Думан 2 Котельная Меркурград 43,284644 77,004677 24 существующий, сайт Алтел 78 AL094 г.Алматы, ул. Марата Оспанова 401/2 п. Первомайский, Илийское шоссе, 12. Филиал АО «Казпочта» Информационно-логистический центр «ЮГ» 43,203267 76,977785 25 существующий, сайт Алтел 43,354267 76,905642 12 существующий, сайт Алтел 80 ATS-21 г.Алматы, ул.Шаляпина, 4 А 43,219451 76,866368 30 существующий, сайт Алтел. Объект КТ 81 Avtobaza г.Алматы, мкр-он Шанырак ул. Берлик 1 43,275947 76,863027 30 82 Kalkaman г.Алматы, ул. Исатая 34 43,219092 76,809277 30 83 mu001 улица Толе би - уг. ул. Варламова 43,247523 76,868730 15 79 AL098 существующий, сайт Алтел. Объект КТ существующий, сайт Алтел. Объект КТ Новый 92 84 mu003 Райымбека проспект, 504 43,246249 76,840801 15 Новый 85 mu004 ул. Искендерова - уг. ул. Жаркентская 43,219248 76,951909 15 Новый 86 mu005 мкр. 2, 55б 43,231218 76,856660 15 Новый 87 mu006 улица Байтурсынова, 67 43,248436 76,926080 15 Новый 88 mu007 мкр. Жетысу-4, д. 16 43,217153 76,838588 15 Новый 89 mu008 мкр 5 д 21Б 43,229921 76,864340 15 Новый. Объект КТ 90 mu010 ул Ладыгина 32 43,206591 76,873240 15 Новый. Объект КТ 91 mu011 ул. Тургенева - уг. ул. Черепанова 43,209394 76,881941 15 Новый 92 mu012 ул. Навои - уг. Алданская 43,218421 76,879752 15 Новый 93 mu013 улица Байкадамова, 28 43,213538 76,891490 15 Новый 94 mu014 улица Аносова, 135 43,243449 76,885570 15 Новый 95 mu015 улица Карасай батыра, 219 43,248378 76,891056 15 Новый 96 mu016 пр. Раимбека - Емцова 43,255384 76,864350 15 Новый 97 mu018 ул. Тимирязева - уг. ул. 20-я линия 43,224292 76,887813 15 Новый 98 mu019 Розыбакиева проспект, 83 43,232574 76,889390 15 Новый 99 mu020 43,257127 76,876098 15 Новый 43,247302 76,800941 15 Новый 101 mu022 улица Брусиловского, 40а п. Алгабас, ул. Байдибек би - уг. ул. Карасай батыра Рыскулова - уг. ул. Биянху 43,270797 76,880170 15 Новый 102 mu023 Рабочий поселок ул.Казакова, 9 43,267516 76,897026 15 Новый. Объект КТ 103 mu024 м-он Казахфильм 37 43,197848 76,907310 15 Новый. Объект КТ 104 mu025 БЦ Атакент, рядом с Нурсатом 43,217087 76,907086 15 Новый 105 mu028 Бухар жырау бульвар, 56 43,230843 76,910018 15 Новый 106 mu029 ул. Жангельдина - уг. ул. Арыковой 43,270843 76,956597 15 Новый 107 mu030 улица Гоголя, 213, элеватор 43,258293 76,907279 15 Новый 108 mu032 ул Гоголя 140/Шагабутдинова 43,257812 76,919100 15 Новый. Объект КТ 109 mu035 улица Гоголя, 2 43,260675 76,963648 15 Новый 110 mu036 улица Бокейханова, 37а 43,278271 76,908676 15 Новый 111 mu037 п. Акжар 43,181373 76,797340 15 Новый 112 mu038 Райымбека проспект, 160а 43,268615 76,924906 15 Новый 113 mu040 Абылай хана проспект, 91 43,256392 76,940793 15 Новый 114 mu041 улица Сатпаева, 13 43,239064 76,948323 15 Новый 115 mu043 ул. Фотиевой - уг. ул. Краснодарская 43,279581 76,931961 15 Новый 116 mu045 улица Богенбай батыра, 245, БЦ Ордабасы 43,250543 76,906033 15 Новый 117 mu046 Суюнбая проспект, 66/1 43,280130 76,947625 15 Новый 118 mu047 Труба на т. ТК "Мерей" 43,273049 76,946664 25 Новый 119 mu050 улица Шевченко, 162е 43,243469 76,910808 15 Новый 120 mu054 мкр. 11, 17 43,225775 76,874686 15 Новый 121 mu055 улица Сатпаева 28 43,236742 76,929749 30 Новый 122 mu056 мкр. Самал-1, д. 33 43,234526 76,951373 15 Новый 123 mu057 улица Коломенская, 3 43,342058 76,941212 15 Новый 124 mu058 улица Байтурсынова, 164 43,228138 76,938928 27 Новый 125 OPS-092 г.Алматы, ОПС-92, ул. Курмангазы,112 43,242781 76,923881 20 существующий, сайт Алтел. Объект КТ 126 ru004 п. Кольсай 43,215004 76,999825 15 Новый 127 ru005 п. Панфилово 43,386660 77,121495 15 Новый 128 ru007 ул. Горная, ресторан выше селезащиты 43,171962 77,036410 15 Новый 129 ru015 улица Байконырская 43,176759 76,970673 15 Новый 130 ru016 вверх по Бутаковке 43,190827 77,024910 15 Новый 131 ru017 ул. Горная - "Бутаковка" 43,189829 76,997129 15 Новый 43,291795 76,961709 30 существующий, сайт Алтел. Объект КТ 100 mu021 132 Shemyakino г.Алматы, ул.Шемякина, 55, ОС-900 133 su002 п.Дружба ул Ленина 22 43,225017 76,830620 15 Новый. Объект КТ 134 su004 п. Каменка, ул. Аксайская - уг. ул. Рыскулова 43,186060 76,828854 15 Новый 93 135 su007 п. Карагайлы 43,169888 76,850266 15 Новый 136 su008 п. Курамыс 43,188924 76,853863 15 Новый 137 su009 мкр. Акбулак, 12 43,258498 76,839006 15 Новый 138 su010 мкр. Шанырак-4, ул. Байтенева-уг. ул. Еркиндик 43,279897 76,836679 15 Новый 139 su012 мкр. Шанырак-1, ул. Коркыт-уг. ул. Утемисулы 43,297368 76,861213 15 Новый 140 su013 мкр. Дархан 43,312932 76,875476 15 Новый 141 su014 м-он Айнабулак-3 д 174 43,321056 76,923280 15 Новый. Объект КТ 142 su016 п. Боралдай, ул. Комсомольская 43,337713 76,858010 15 Новый 143 su018 п. Боралдай 43,365925 76,859028 15 Новый 144 su019 улица Высоковольтная, 20 43,343202 76,909511 15 Новый 145 su021 м-он Дорожник 35 43,302200 76,900049 15 Новый. Объект КТ 146 su022 улица Чехова, 37 43,330820 76,940726 15 Новый 147 su023 улица Эйхе, 23 43,357684 76,936623 15 Новый 148 su024 п.Мамыр ул кассина 18А 43,307453 76,935518 15 Новый. Объект КТ 149 su026 43,360106 76,992378 15 Новый 43,373282 76,944671 15 Новый 151 su028 мкр. Жулдыз-2, 39а п. Первомайка, ул. Вокзальная - уг. ул. Молодежная ул.Комунаров 70А 43,327103 76,968974 15 Новый. Объект КТ 152 su031 Илийский тракт, д. 659 43,390482 77,003905 15 Новый 153 su032 Сейфуллина проспект, 515 43,258327 76,931853 15 Новый 154 su033 п. Энергетический, Илийский тракт, здание на въезде 43,408741 77,015311 15 Новый 155 su034 улица Бегалина, 82 43,249227 76,967106 15 Новый 156 su039 п. Колхозшы, здание автодрома 43,328426 77,013697 15 Новый 157 su040 п. Гульдала 43,344398 77,046652 15 Новый 158 su041 п. Гульдала 43,354518 77,062707 15 Новый 159 su042 п. Туздыбастау 43,309596 77,062994 15 Новый 160 su043 п. Туздыбастау 43,327157 77,059034 15 Новый 161 su045 улица Шемякина, 192а 43,303622 76,965436 15 Новый 162 su046 ул. Станиславского - уг. ул. Таирова 43,283342 76,967390 15 Новый 163 su047 п. Бесагаш 43,290603 77,029422 15 Новый 164 su052 улица Радлова, 124 43,236816 76,969461 15 Новый 165 su053 Санаторий Турксиб ул.Оспанова 160 43,195489 76,972205 15 Новый. Объект КТ 166 su055 мкр. Калкаман-3 43,208504 76,826653 15 Новый 167 su056 Каменское плато 43,177150 76,953007 15 Новый 168 su057 Ремизовка 43,196480 76,927896 15 Новый 169 su059 п. Энергетик 43,164882 76,898517 15 Новый 170 su060 Комплекс "Олимпик Плаза", по ул. Дулати 43,152870 76,895501 15 Новый 171 su061 Ремизовка 43,184888 76,925971 15 Новый 172 su062 п. Бесагаш 43,300650 77,054990 15 Новый 173 su071 Шаляпина - Саина, мкр. Мамыр 43,213573 76,855518 15 Новый 174 su072 сан. Алтын Каргалы, ул. Адилова - уг. ул. Сейлбека Исаева 43,197851 76,862851 15 Новый 175 su073 п. Вторая Пятилетка, ул. Центральная - уг. Жакабая Отегенова 43,176832 76,897395 15 Новый 176 su074 улица Хантенгри, напротив д. 101 43,276749 76,997695 15 Новый 177 su075 улица Сарбайская, 123 43,288406 76,982811 15 Новый 178 su076 мкр. Шанырак-2, ул. Жанкожа батыра - уг. Култегин 43,284606 76,851143 15 Новый 179 su077 мкр. Шанырак-2, ул. Жалантос бахадур 43,304832 76,853185 15 Новый 180 su078 Сейфуллина проспект, 97 43,316663 76,938985 15 Новый 181 su079 поселок Коянкус 43,391962 76,943197 15 Новый 182 su080 улица Радус-Зенковича, 13 43,362957 76,964792 15 Новый 183 su081 Первомайский переулок (севернее нефтебазы) 43,356251 76,924047 15 Новый 184 su082 п. Энергетический, Илийский тракт - уг. Ул. Дзержинского 43,424264 77,023385 15 Новый 150 su027 94 185 su083 п. Жана Куат 43,396427 77,031192 15 Новый 186 su084 п. Энергетический, Илийский тракт, логистический центр ДАМУ 43,453568 77,032256 15 Новый 187 su086 улица Айша Биби, 116 43,306231 76,979440 10 Новый 188 su087 мкр. Маяк, улица Капчагайская, 24 43,333762 76,992237 10 Новый 189 su088 мкр. Заря Востока, улица Садовая, 126 43,282974 76,881766 10 Новый 190 su089 мкр. Улжан-2 43,297575 76,880680 10 Новый 191 su090 улица Майбороды, 24 43,325070 76,951776 12 Новый 192 su091 улица Павлодарская, 133а 43,332405 76,921076 15 Новый 193 su092 улица Есенберлина, 149 43,266016 76,973022 25 Новый 194 su093 улица Руставели, 3 43,299799 76,953593 12 Новый 195 su094 пр. Раимбека - ЖК рядом с оптомаркетом "Арзан" мкр. Аккент 43,243223 76,812639 30 Новый 196 su095 ул. Серикова 43,296664 76,913694 15 Новый 197 su096 мкр. Самал 3, д. 25 43,227523 76,952347 50 Новый 198 su097 улица Шакарима - уг. улица Маршака 43,242630 76,876147 60 Новый 199 su098 улица Кудерина, 14 43,262835 76,885279 10 Новый 200 su099 мкр. Айгерим, 2 43,270905 76,851467 15 Новый 201 su100 Рыскулова проспект, 170а 43,265556 76,867886 10 202 Uzhet г.Алматы, мкр-он Ужет, ул. Ауэзова, 50В 43,323377 76,885821 30 Новый существующий, сайт Алтел. Объект КТ Список сайтов в г. Астана Высота подвеса антенн № ID объекта 1 AS001 г.Астана,пр. Абая, 78, АМТС 51,167778 71,425552 30 2 AS002 г.Астана, микр.4, АТС-35 51,15136 71,473747 48 3 AS003 г.Астана,ул.Литейная, 7. АТС-77 51,191543 71,411071 36 4 AS004 г.Астана, пр. Кабанбай батыра, 19. Университет 51,144444 71,422501 21 существующий, сайт Алтел 5 AS005 г.Астана,ул. Сары-Арка, 84 (СОП) 51,174721 71,406944 34 существующий, сайт Алтел 6 AS006 г.Астана, Аэропорт Астаны 51,032406 71,464488 16 существующий, сайт Алтел 7 AS007 г.Астана, Сары-Арка 3, стадион Каспий 51,153137 71,408264 26 существующий, сайт Алтел 8 AS008 г. Астана, ул. Достык 13, ЖК "Нурсая", южная сторона, 8-й подъезд, 51,126718 71,435331 48 существующий, сайт Алтел 9 AS009 г.Астана ул.Угольная, 24 Элеватор "Цесна" 51,185001 71,459167 53 существующий, сайт Алтел 10 AS010 г. Астана, ул. Дукенулы 31 "Рынок Асем" 51,18111 71,435555 21 существующий, сайт Алтел 11 AS011 г. Астана, мкр. Аль_фараби д.10/1, ЖСК “Дольщик” 51,157902 71,494041 36 существующий, сайт Алтел 12 AS012 г.Астана ул.Ташенова 50/1, "Эдельвейс" 51,151669 71,436386 42 существующий, сайт Алтел 13 AS013 c. Коктал, ул. Бабатайулы 3/1 51,1805 45 существующий, сайт Алтел. Объект КТ 14 AS014 г.Астана пос."Караоткель-2" ул. Имантау, 12 51,150211 71,401587 28 Новый 51,128613 71,535271 39 существующий, сайт Алтел 32 существующий, сайт Алтел. Объект КТ Адрес г.Астана ул.Зайчуковой, 8 Элеватор "Промышленный" г. Астана, мкр. Целинный, АТС37 (комната СТОП Широта Долгота 71,3367 Примечание существующий, сайт Алтел. Объект КТ существующий, сайт Алтел. Объект КТ существующий, сайт Алтел. Объект КТ 15 AS015 16 AS016 17 AS017 г.Астана, мкр. Арман ул. Кривогуза, 2/1 51,200554 71,390831 20 существующий, сайт Алтел 18 AS018 г.Астана, ул. Байсековой 4/1 строение 1 51,181389 71,386108 16 существующий, сайт Алтел 19 AS019 г.Астана ул. Абая, д.50, КСК "Океан" 51,169739 71,442146 35 существующий, сайт Алтел 20 AS020 г. Астана, ул. Пионерская д. 31. ТЦ "Атамекен" 51,145279 71,512222 21 существующий, сайт Алтел 21 AS021 г. Астана, пр. Момышулы д. 4. КСК "Женис" 51,137011 71,469092 33 существующий, сайт Алтел 22 AS022 г. Астана, ул. Алма-Ата 1, БЦ "Асыл Тау" 51,118332 71,414444 70 существующий, сайт Алтел AS023 г. Астана, ул. Тауелгыздык 33, Главный Телекоммуникационный центр 51,130783 71,434486 90 существующий, сайт Алтел. Объект Казтелерадио 23 51.158722 71.455331 95 24 AS024 г. Астана, пос. Чубары ул. Жанатая Шарденова, 22 51,139971 71,429313 10 Новый 25 AS025 г. Астана, ул. Сейфулина уг. Алманова 51,172354 71,429942 25 Новый. Объект КТ 26 AS026 51,187119 71,452187 40 Новый. Объект КТ 27 AS027 51,154369 71,48951 20 Новый. Объект КТ 28 AS028 г. Астана, RSU-6 - ул. Угольная, 14 А г. Астана, пр.Абылай-хана, 33/1 (в жилом доме) г. Астана, Соборная мечеть пр. Тауелсиздик 51,125654 71,473116 22 Новый 29 AS029 27 Новый AS030 51,15227 71,521847 12 Новый. Объект КТ 31 AS031 г. Астана, ул. Иманбаевой, 7 г. Астана, мкр.Аль-Фараби, 77 (в жилом доме) г. Астана, пр. Момышулы, 27 51,161733 71,435264 30 51,142894 71,491581 32 Новый 32 AS032 51,148533 71,481162 36 Новый 33 AS033 51,153795 71,448697 15 Новый. Объект КТ 34 AS034 51,171058 71,464278 12 Новый. Объект КТ 35 AS035 г. Астана, ул. Куйши Дина, 28, 28/1 г. Астана, мкр.Молодежный, 21 (в жилом доме) г. Астана, ул.Брусиловского,79/1 (в жилом доме г. Астана, ул.Кеменгерулы, 23 51,200043 71,407272 8 Новый. Объект КТ 36 AS036 г. Астана, пр. Республики, 64 51,185529 71,422167 12 Новый. Объект КТ 37 AS037 г. Астана, шоссе Алаша 51,204325 71,48661 8 Новый 38 AS038 г. Астана, пос. Кунгейжар 51,107531 71,682521 6 Новый 39 AS039 51,12623 71,594962 8 Новый 40 AS040 51,170148 71,379204 12 Новый 41 AS041 г. Астана, пос. Учхоз, ул. Нурлыжол г. Астана, ул. Сейфулина возле канала Сарыбулак г. Астана, ул. Коктал, 11 51,215467 71,344679 10 Новый 42 AS042 г. Астана, пр. Тауелсиздик 51,110961 71,461111 10 Новый 43 AS043 г. Астана, пос. Мичурина 51,118863 71,63579 8 Новый 44 AS044 г. Астана, пр. Кабанбай Батыра, 28 51,134932 71,416443 15 Новый 45 AS045 г. Астана, Туран проспект, 36 51,120545 71,403964 18 Новый 46 AS046 г. Астана, Назарбаев Университет 51,089728 71,400206 21 Новый 47 AS047 г. Астана, поселок Пригородный, 126 51,04396 71,428214 18 Новый 48 AS048 г. Астана, ул. Аль-Фараби, 23 51,251564 71,378376 10 Новый 49 AS049 г. Астана, Кургальжинское шоссе, 8 51,148838 71,379925 30 Новый 50 AS050 г. Астана, пр. Нургисы Тлендиева угол ул. Улытау 51,190655 71,339801 45 Новый 51 AS051 г. Астана, ул. Александра Затаевича, 8 51,189084 71,400954 20 Новый 52 AS052 г. Астана, ул. Мугалжар, 84 51,104066 71,436767 12 Новый 53 AS053 г. Астана, ул. Шарбакты, 1в 51,121474 71,522282 20 Новый 54 AS054 г. Астана, ул. Владимира Маяковского, 3/1 51,146012 71,56502 - Новый 55 AS055 г. Астана, ул. №1 д.21 51,134392 71,365308 36 Новый 56 AS056 г. Астана, ул. Нагорная, 23/1 51,155468 71,396211 - Новый 57 AS057 г. Астана, ул. Орынбор угол ул. 44 51,096092 71,429881 15 Новый 58 AS058 г. Астана, ул. Амангельды Иманова, 26 51,163898 71,443837 50 Новый 59 AS059 г. Астана, ул. Сыганак, 21 51,124083 71,425962 45 Новый 60 AS060 г. Астана, ул. Кенесары, 14 51,162655 71,412381 20 Новый 61 AS061 51,167076 71,41318 15 Новый 62 AS062 51,126945 71,489543 36 Новый 63 AS063 г. Астана, пр. Абая, 23 г. Астана, ул. 12-я магистраль "ТурсынАстана" г. Астана, ул. Орынбор 51,116339 71,439028 48 Новый 64 AS064 г. Астана, ул. Кордай, 62 51,131811 71,504554 45 Новый 65 AS065 г. Астана, ул. Габидена Мустафина, 15 51,154946 71,510094 33 Новый 66 AS066 г. Астана, пр. Абылай Хана, 51 51,150852 71,49871 32 Новый 67 AS067 г. Астана, пр. Момышулы, 14 51,140243 71,481002 40 Новый 68 AS068 г. Астана, ул. Шамши Калдаяков, 11 51,118415 71,461893 66 Новый 69 AS069 г. Астана, 5 микрорайон, 3 51,156177 71,47591 30 Новый 70 AS070 г. Астана, ул. 60, 1 51,186446 71,487313 - Новый 71 AS071 г. Астана, шоссе Алаша, 12 51,196679 71,474281 - Новый 72 AS072 г. Астана, пр. Манаса, 16 51,146671 71,46049 15 Новый 73 AS073 г. Астана, ул. 85, 5/3 51,208338 71,443472 15 Новый 74 AS074 г. Астана, ул. Телжан Шонанулы, 43 51,196 18 Новый 71,430328 96 75 AS075 г. Астана, ул. 34, 24/1 51,208723 71,404225 10 Новый 76 AS076 г. Астана, ул. Сакена Сейфуллина, 65 51,172332 71,454241 40 Новый 77 AS077 г. Астана, ул. Акжол, 32 51,179961 71,470742 - Новый 78 AS078 г. Астана, пр. Абая, 72а 51,167604 71,455666 8 Новый 79 AS079 г. Астана, ул. Габдуллина, 17/1 51,165033 71,430898 45 Новый 80 AS080 г. Астана, ул. Маскеу, 35 51,183446 71,411357 80 Новый 81 AS081 г. Астана, ул. Шара Жиенкулова, 18/2 51,181134 71,451094 10 Новый 82 AS082 г. Астана, ул. Бейбитшилик, 25 51,172179 71,418749 12 Новый 83 AS083 г. Астана, ул. Сарайшык 51,12849 71,458652 40 Новый 84 AS084 г. Астана, пр. Богембай батыра, 54 51,17459 71,396792 36 Новый 85 AS085 г. Астана, пр. Республики, 46 51,177538 71,424502 18 Новый 86 AS086 г. Астана, Ак-Булак-3 микрорайон, 34 51,139381 71,449393 15 Новый 87 AS087 г. Астана, пр. Туран 51,10737 71,402211 30 Новый 88 AS088 г. Астана, ул. Орынбор, 21/1 51,114485 71,431073 36 Новый 89 AS089 г. Астана, ул. Орынбор 51,092325 71,424509 6 90 AS090 51,105319 71,41938 36 91 AS091 51,15761 71,428389 40 92 AS092 г. Астана, ул. Сауран, 12/1 г. Астана, ЖК на пр. Республика (набережная) г. Астана, ул. Туркистан, 2 Новый Новый 51,119338 71,429455 36 Новый Новый 93 AS093 51,144924 71,4722 30 Новый 94 AS094 51,140429 71,403999 8 95 AS095 г. Астана, ул. Мирзояна,31 г. Астана, пос."Комсомольский" ул. Айганым, 10 г. Астана, ул. Петрова, 26/1 51,163061 71,460094 30 Новый 96 AS096 г. Астана, пр. Туран, 14 51,142699 71,41297 32 Новый 97 AS097 г. Астана, Кургальджинское шоссе, 21 51,146903 71,370625 28 Новый 98 AS098 г. Астана, Кургальджинское шоссе, 4 51,148094 71,394615 36 Новый Новый 99 AS099 г. Астана, пр.Абая, 1 51,165319 71,401342 10 Новый. Объект КТ 100 AS100 г. Астана, ул.Талапкерская, 5 51,183139 71,374451 10 Новый. Объект КТ 101 AS101 г. Астана, ул.Бейбитшилик, 41 51,178421 71,417349 15 Новый. Объект КТ 102 AS102 г. Астана, ул. Московская уг. Фрунзе 51,180659 71,402653 30 Новый 103 AS103 г. Астана улица А. Байтурсынова, 71 51,188786 71,385192 10 Новый 104 AS104 г. Астана, ул. Строительная 51,2006 71,359723 8 Новый 105 AS105 51,178428 71,354644 8 Новый 106 AS106 51,170716 71,494594 - Новый 107 AS107 г. Астана улица 150 Лет Абая, 22/1 г. Астана возле реки Акбулак по ул. Вишневского г. Астана поселок Ондирис 51,22998 - Новый 108 AS108 г. Астана мкр. Энергетик, ул. Шукшина 51,145786 71,44885 30 Новый 109 AS109 г. Астана ул. Жумабаева 51,136889 71,490864 8 Новый 110 AS110 г. Астана, ул. Малахова возле ж/д 51,209757 71,382649 10 Новый 111 AS111 г. Астана дачи в районе КазГЮУ 51,159058 71,372354 - Новый 112 AS112 г. Астана ул. Кабанбай батыра 51,127159 71,410817 25 Новый 113 AS113 г. Астана, ипподром Астаны 51,071311 71,391739 - Новый 114 AS114 г. Астана, на ул. Пушкина возле ж/д 51,170685 71,477012 - Новый 115 AS115 г. Астана, ул. Жалина угол ул. Жукова 51,192917 71,367031 6 Новый 116 AS116 г. Астана, мкр. Акбулак на ул. Токпанова 51,137759 71,457497 20 Новый 71,370905 97 Приложение 2 Границы г. Алматы Рис. 2.1 Файл Google Earth – Зона Алматы и пригород.kmz 98 Граница г. Астана Рис 2.2 Файл Google Earth – Зона Астаны и пригород.kmz 99 Приложение 3 к тендерной документации по закупу сетевого оборудования и услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения (4G) на базе технологии LTE «под ключ» Форма заявки на участие в тендере Кому: ________________________________________________________ (указывается наименование Заказчика) От кого: _______________________________________________________ (указывается наименование потенциального поставщика) 1. Сведения о юридическом лице, претендующем на участие в тендере (потенциальном поставщике): Полное наименование юридического лица – потенциального поставщика (в соответствии со свидетельством о государственной регистрации) Номер и дата свидетельства о государственной регистрации юридического лица Регистрационный номер налогоплательщика Юридический, почтовый адрес и адрес электронной почты, контактные телефоны, потенциального поставщика Банковские реквизиты юридического лица (включая полное наименование, РНН, БИК, ИИК и адрес банка или его филиала) Ф.И.О. первого руководителя юридического лица 2. ________________(указывается полное наименование юридического лица) настоящей заявкой выражает желание принять участие в закупках способом тендера __________________(указать полное наименование тендера) в качестве потенциального поставщика и выражает согласие осуществить (поставку товара(ов), выполнение работ, оказание услуг – указать необходимое), в соответствии с требованиями, условиями и сроками, предусмотренными тендерной документацией. 3. Потенциальный поставщик настоящей заявкой подтверждает, что он ознакомлен с тендерной документацией и осведомлен об ответственности за предоставление __________ (указать наименование Заказчика) и тендерной комиссии недостоверных сведений о своей правомочности, качественных и иных характеристиках _________ (поставляемого товара(ов), выполняемых работ, оказываемых услуг – указать необходимое) соблюдении им авторских и смежных прав, а так же иных ограничений. 100 Потенциальный поставщик принимает на себя полную ответственность за представление в данной заявке на участие в тендере и прилагаемых к ней документах таких недостоверных сведений. 4. Перечень прилагаемых документов: N п\п Наименование документа Оригинал или копия Количество листов 5. Данная заявка на участие в тендере прошита, пронумерована и последняя страница скреплена подписью первого руководителя и печатью потенциального поставщика на _____ листах. 6. К данной заявке на участие в тендере прилагается обеспечение заявки на участие в тендере в виде _____________ (банковская гарантия, кассовый чек, приходный ордер, платежное поручение - указать необходимое) на ___ листах. 7. К данной заявке на участие в тендере прилагается Техническая спецификация на (поставляемый товар(ы), выполняемые работы, оказываемые услуги - указывается необходимое), прошитая, пронумерованная и последняя страница скреплена подписью первого руководителя и печатью потенциального поставщика на ____ листах. 8. Настоящая заявка на участие в тендере действует в течение ___ дней. 9. До момента заключения договора о закупках настоящая заявка на участие в тендере вместе с Вашим уведомлением о признании ее выигравшей будет выполнять роль обязательного договора между нами. ________________________________ ___________________/____________/ (Должность, Ф.И.О. первого руководителя юридического лица - потенциального поставщика и его подпись) Дата заполнения ____________ М.П. 101 Приложение 4 к тендерной документации по закупу сетевого оборудования и услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения (4G) на базе технологии LTE «под ключ» ________________________________ полное наименование тендера по лоту (ам)__ «__________________» полное наименование лота Форма ценового предложения потенциального поставщика _____________________________________________________ (наименование потенциального поставщика) Таблица цен для Лота №_____ № п/п 1 2 3 4 5 6 7 8 9. 10. Содержание Стоимость Краткое описание товара, работы, услуги Страна происхождения (при закупках работ и услуг исключить) Завод-изготовитель (при закупках работ и услуг исключить) Единица измерения Цена _________за единицу в ______ на условиях _______________ ИНКОТЕРМС 2000/2010 (пункт назначения) Количество (объем) Всего цена = стр.5 х стр.6, в _______ Общая цена, в ___________ (валюта) на условиях на условиях ________ г. _____________ ИНКОТЕРМС 2000/2010 пункт назначения, включая все расходы потенциального поставщика на транспортировку, страхование, уплату таможенных пошлин, без НДС и других налогов, платежей и сборов, стоимость комплектующих деталей и обязательных запасных частей, обслуживания в течение начального срока эксплуатации на единицу измерения, другие расходы, в том числе: Гарантийный период Сроки поставки и оказания услуг Таблицы цен заполняются в обязательном порядке всеми участниками тендера отдельно на каждый Лот. Потенциальный поставщик вправе указать другие расходы, в том числе: размер скидки, в случае ее представления 102 Мы согласны с Вашими условиями платежа, оговоренными в тендерной документации. Предлагаем следующие альтернативные условия платежа ____________________________________________________________________ (перечисляются альтернативные условия платежа, если таковые имеются) или другие условия (перечислить______________________________________________________) при этом предоставляем ценовую скидку в размере _________________________________________ (указать в денежном выражении, прописью) ______________ (Подпись) М.П. ____________________________ (Должность, ФИО) Примечание: потенциальный поставщик может не указывать составляющие общей цены, при этом указанная в данной строке цена рассматривается тендерной комиссией как определенная с учетом всех затрат потенциального поставщика и не подлежит пересмотру. 103 Приложение 5 к Тендерной документации по закупу сетевого оборудования и услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения (4G) на базе технологии LTE «под ключ» Банковская гарантия (форма обеспечения тендерной заявки) Наименование банка________________________________________________ (наименование и реквизиты банка) Кому__________________________________________________________ (наименование и реквизиты Заказчика) Гарантийное обязательство №_______ _________________ (местонахождение) «___»_________ _____________г. Мы были проинформированы, что__________________________ (наименование потенциального поставщика) в дальнейшем «Поставщик», принимает участие в тендере по закупке _________________________________________________________, организованном__________________________________________________________________ _____________________________________ (наименование Заказчика) и готов осуществить поставку (выполнить работу, оказать услугу) ________________________________ на общую сумму __________ тенге. (наименование и объем товаров, работ и услуг) (прописью) Тендерной документацией от «___»__________ _____ г. по проведению вышеназванных закупок предусмотрено внесение потенциальными поставщиками обеспечения тендерной заявки в виде банковской гарантии. В связи с этим мы ______________________ настоящим берем на себя (наименование банка) безотзывное обязательство выплатить Вам по Вашему требованию сумму, равную ________________________________________________________________________________ ____________________________________ (сумма в цифрах и прописью) по получении Вашего письменного требования на оплату, а также письменного подтверждения того, что Поставщик: отозвал или изменил тендерную заявку после истечения окончательного срока представления тендерных заявок; не подписал, в установленные сроки, договор о закупках; не внес обеспечение исполнения договора о закупках после подписания договора о закупках в форме, объеме и на условиях, предусмотренных в тендерной документации. Данное гарантийное обязательство вступает в силу со дня вскрытия конвертов с тендерными заявками Данное гарантийное обязательство действует до окончательного срока действия тендерной заявки Поставщика на участие в тендере и истекает полностью и автоматически, независимо от того, будет ли нам возвращен этот документ или нет, если Ваше письменное требование не 104 будет получено нами к концу _____________. Если срок действия тендерной заявки продлен, то данное гарантийное обязательство продлевается на такой же срок. Все права и обязанности, возникающие в связи с настоящим гарантийным обязательством, регулируются законодательством Республики Казахстан. Подпись и печать гаранта Дата и адрес 105 Приложение 6 к Тендерной документации по закупу сетевого оборудования и услуг по планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети мобильной связи четвертого поколения (4G) на базе технологии LTE «под ключ» ДОГОВОР О ЗАКУПКАХ ТОВАРОВ, РАБОТ И УСЛУГ №________ /__________ «____» _________ 2011 года, г. Алматы АО «АЛТЕЛ», именуемое в дальнейшем «Заказчик», в лице Президента Суранбекова Максута Тельмановича, действующего на основании Устава, с одной стороны, И «_________________», именуемое в дальнейшем «Поставщик», в лице ___________, действующего на основании __________, с другой стороны, далее совместно именуемые «Стороны», а по отдельности «Сторона», на основании Протокола об итогах тендера по закупке _______ заключили настоящий Договор (далее Договор) и пришли к соглашению о нижеследующем: 1. Предмет Договора 1.1. Поставщик обязуется поставить телекоммуникационное оборудование, программное обеспечение и лицензии (далее – Оборудование), на условиях DAP/DDP объекты установки в г.Алматы, г.Астана согласно условиям ИНКОТЕРМС-2010 в соответствии со Спецификацией, приведенной в Приложении №1 к Договору и оказать услуги по управлению поставкой Оборудования, проектированию, планированию, строительству, монтажу и пуско-наладке, сдаче в эксплуатацию сети на условиях «под ключ» (далее – Услуги), а Заказчик обязуется принять Оборудование и оказанные Услуги и оплатить стоимость поставленного Оборудования и оказанных Услуг на условиях Договора. Определение склада / складов временного хранения, на которое поставляется Оборудование (далее - Место назначения) осуществляется дополнительно по согласованию Поставщика и Заказчика в письменном виде до начала осуществления поставки каждой партии Оборудования. 1.2. Перечисленные ниже Приложения и условия, оговоренные в них, входят в состав данного Договора и являются его неотъемлемой частью, а именно: 1.2.1 Приложение №1 – «Спецификация Оборудования и Услуг»; 1.2.2 Приложение №2 – «Техническое задание на построение сети»; 1.2.3 Приложение №3 – «Распределение обязанностей по установке и материалам»; 1.2.4 Приложение №4 – «График реализации проекта»; 1.2.5 Приложение№5. – «Форма акта приема-передачи Оборудования» 1.2.6 Приложение №6. – «Форма акта приемки-сдачи оказанных Услуг»; 2. Обязательства Сторон 2.1. Поставщик обязуется: 2.1.1. Обеспечить в срок 30.11.2012 ввод Сети в коммерческую эксплуатацию. 2.1.2. Обеспечить проектирование сети, гарантирующее достижение заданных значений показателей качества (KPI), в соотвествии с п.2.3.3. Приложения №2 «Техническое задание на построение сети». Значения KPI должны быть гарантированы как в ходе приемки в Сети эксплуатацию, так и в период 6-месячной тестовой эксплуатации сети с увеличением количества абонентов Сети согласно Приложению №2. В случае, если показатели покрытия и качества KPI не достигнуты в ходе приемки Сети в эксплуатацию и/или в период тестовой 106 эксплуатации сети, Поставщик обязан за свой счет допоставить необходимое количество дополнительного оборудования и программного обеспечения, и соответствующий объем услуг - для приведения в соответствие фактических уровней с заданными уровнями показателей покрытия и качества KPI. 2.1.3. Обеспечить управление поставкой Оборудования и движением товарно-материальных ценностей при исполнении Договора, в том числе: - поставка Оборудования до мест назначения, указанных в Приложении №1 к Договору на условиях Договора; - информирование Заказчика за 3 календарных дня до начала отгрузки Оборудования о времени и сроках поставки Оборудования по факсу либо по электронной почте; - складирование и хранение Оборудования в условиях, отвечающих соответствующим требованиям производителя; - проверка комплектности поставки на соответствие Приложению№1 и обеспечение в случае необходимости допоставки Оборудования; - комплектование Оборудования и доставку на объекты установки согласно спецификациям / проектной документации, разработанным для каждого объекта сети; - передачу Заказчику ЗИП, а также остатков оборудования и материалов, не использованных в процессе монтажа; - предоставить сертификат происхождения и сертификат соответствия Республики Казахстан, выданный юридическим лицом, аккредитованным Госстандартом Республики Казахстан, с первой партией поставляемого Оборудования. Все расходы по сертификации Поставщик берет на себя; 2.1.4. Обеспечить проектирование объектов сети, в том числе: - планирование покрытия радиосети с определением перечня позиций, географических координат центра района и радиус поиска, высоты установки антенной системы, количество обследуемых кандидатов; - уточнение параметров расчетной модели радиосети; - планирование емкости радиосети; - обеспечить поиск объектов установки Оборудования, удовлетворяющих проектным критериям; - провести оценку объектов-кандидатов на соответствие проектным критериям, оценить любые потенциальные проблемы и принять решение о строительстве; - обеспечить заключение Договора аренды объекта согласно (ссылка на матрицу распределения обязанностей и критериям Заказчика по формату и условиям оплаты); - в случае необходимости обеспечить получение Технических Условий (далее - ТУ) на отдельные работы по Договору, и обеспечить за свой счет исполнение ТУ, включая оформление соответствующих Актов; - разработать проектную документацию на общестроительные, специальные работы и установку Оборудования, включая детальную спецификацию компонентов и материалов; - в рамках проектных работ обеспечить расчет и согласование санитарно-защитных зон, получение санитарных паспортов на объекты радиосети; - обеспечить в случае необходимости проведение за свой счет экспертиз проектной документации с получением соответствующих заключений; - обеспечить сбор данных и подготовку документов для получения необходимых разрешений государственных органов для ввода объектов в эксплуатацию. 2.1.5. Обеспечить управление проведением монтажных работ; 2.1.6. Обеспечить интеграцию подсистем Оборудования согласно требованиям Заказчика Приложения №2. 2.1.7. Обеспечить предъявление объектов Заказчику и проведение приемо-сдаточных испытаний; 2.1.8. Сдать Объект(ы) установки Оборудования в соответствии с техническими требованиями Приложение №2; 2.1.9. По факту оказания Услуг на условиях Договора, обеспечить подписание соответствующих Актов и представить Заказчику счета-фактуры (инвойсы) на сумму 107 оказанных Услуг; 2.1.10. Поставщик обязан обеспечить включение полного лицензирования максимальной емкости (производительности) аппаратной части поставляемого Оборудования. Поставщик обязуется не устанавливать искусственные ограничения (программные или иные ключи активации), которые могут ограничить использование оборудования в рамках максимальной физической емкости или производительности. Поставщик ни полностью, ни частично не должен передавать кому-либо свои обязательства по Договору без предварительного письменного согласия Заказчика; 2.2. Заказчик обязуется: принять поставляемое Оборудование и Услуги в порядке и на условиях Договора; оплатить стоимость поставленного Оборудования и оказанных Услуг в порядке и на условиях Договора; оказывать Поставщику полное содействие для исполнения Поставщиком своих обязательств по настоящему Договору; нести другие обязательства, предусмотренные Договором. 3. Цена и общая сумма Договора 3.1. Общая стоимость Оборудования на условиях DAP/DDP (Доставка до назначения Инкотермс 2010) составляет __________ (_________________) _________ (далее Общая стоимость Оборудования), и состоит из суммы цен на каждую единицу поставленного Оборудования, указанного в Спецификациях (Приложение №1 к Договору), включая транспортировку до мест назначения. 3.2. Общая стоимость Услуг, оказываемых по Договору составляет ____________ (___________________) __________, (далее Общая стоимость Услуг), в том числе: стоимость монтажа и пусконаладочных работ, передаваемых на субподряд резиденту Республики Казахстан, в соответствии со стоимостью указанной в Спецификациях (Приложение №1 к Договору) 3.3. Общая стоимость Договора составляет _____________ (________________) __________ (далее Общая стоимость Договора). 3.5. Цены, зафиксированные в пунктах 3.1., 3.2., 3.3 не могут быть изменены в течение всего срока действия Договора. Не являются основанием для изменения цены факты увеличения транспортных расходов, инфляционные процессы, а также иные обстоятельства, обусловленные экономическими причинами или действием обстоятельств непреодолимой силы. 4. Условия платежа 4.1. Оплата по Договору за поставляемое Оборудование будет осуществляться следующим образом: - 15% (пятнадцать процентов) предоплата от общей стоимости Оборудования в размере _____________ (______________)оплачиваются в течение 30 (тридцать) календарных дней с момента подписания Договора; - 85% (восемьдесят пять процентов) от общей стоимости Оборудования в размере ____________ (______________________)оплачивается равными полугодовыми платежами в течение 3 (трех) лет с момента подписания Акта окончательной приемки сети; 4.2. Общая стоимость за оказываемые Услуги, указанная в пункте 3.2. Договора, должна быть оплачена следующим образом: - 15% (пятнадцать процентов) предоплата от общей стоимости Услуг в размере ________ (__________) в размере _____ оплачиваются в течение 30 (тридцать) календарных дней с момента подписания Договора; - 35% (тридцать пять процентов) от общей стоимости Услуг в размере __________ (__) (__________) оплачиваются в течение 30 (тридцать) календарных дней со дня получения Заказчиком официального уведомления от Поставщика о готовности всех Объектов к монтажу. 108 Допускаются частичные выплаты по факту получения Заказчиком официального уведомления от Поставщика о готовности группы объектов к монтажу (группа должна быть не менее 10 объектов) а к уведомлению должны быть приложены оригиналы документов, подтверждающих факт выполнения работ; - 50% (пятьдесят процентов) от общей стоимости Услуг в размере ____________ (______________________) в размере _____ оплачивается в течение 30 (тридцать) календарных дней со дня подписания Акта окончательной приемки сети. 4.3. Все финансовые расходы, возникающие при доставке оборудования от Поставщика до места поставки (включая перевозку, таможенные процедуры, оплату пошлин и получение разрешительных документов на импорт), несет сторона, согласно принятым Договором условиям поставки DDP/DAP (Инкотермс 2010). 4.4. Банковские расходы, возникающие при исполнении Договора на территории страны Заказчика, оплачиваются Заказчиком, вне территории страны Заказчика - получателем платежа. 5. Сроки поставки Оборудования и оказания Услуг 5.1. Поставка Оборудования и оказание Услуг должны быть произведены в сроки согласно графику, приведенному в Приложении №4. 5.2. Датой поставки Оборудования на условиях DAP/DDP (Инкотермс 2010) считается дата подписания Cторонами Актов проверки поставки Оборудования до Мест установки. 5.3. Датой оказания Услуг по Договору считается дата подписания Акта окончательной приемки Сети (FAC). По взаимному согласованию Стороны могут подписывать Акты предварительной приемки (PAC), фиксирующие исполнение отдельных обязательств Сторон и графика работ по Договору. 5.4. Смешанная транспортировка и частичная отгрузка при поставке Оборудования в рамках Договора разрешены. 5.5. Каждая партия отгруженного Оборудования должна иметь следующие сопроводительные документы: инвойс – 1 оригинал и 2 копии; транспортную накладную - 1 оригинал и 3 копии; упаковочный лист – 1 оригинал и 1 копия; сертификат соответствия, 1копия; копию экспортной декларации сертификат происхождения -1 оригинал и 1 копия; техническое описание на русском и английском языках. В упаковочном листе должна содержаться информация о штрих-кодированном номере места. Заказчик в течение 2 (два) рабочих дней со дня получения вышеперечисленных документов должен подтвердить Поставщику в письменном виде свое согласие с содержанием таких документов либо направить мотивированный отказ, в противном случае содержание таких документов считается согласованным Сторонами. 5.6. В течение 48 (сорок восемь) часов после начала отгрузки Оборудования Поставщик должен направить Заказчику экспресс почтой DHL или другим аналогичным путем следующие документы: инвойс, 1 оригинал и 1 копия; транспортную накладную, 1 оригинал и 1 копия; упаковочный лист, 1 оригинал и 1 копия; сертификат происхождения Оборудования,1 оригинал; сертификат соответствия, 1копия; копию экспортной декларации; техническое описание Оборудования на русском и английском языке. 109 5.7. Оборудование будет поставлено в комплектации, количестве и на условиях, определенных в Приложении №1 к Договору. 5.8. Поставщик несет ответственность за недостоверность информации, содержащейся в сопроводительных документах, указанных в пунктах 5.5, 5.6. Договора. 5.9. По письменному запросу Поставщика Заказчик до начала оказания Услуг может получить и предоставить Поставщику все разрешения, которые могут требоваться в связи с выполнением монтажных работ, такие как, но не ограничиваясь перечисленным: специальные разрешения, необходимые для перевозки, проезда к месту монтажа Оборудования, пропуски для прохода в здания и монтажные площадки, где будут вестись работы. При необходимости проведения обследования, согласно пункту 2.1. Договора, такие пропуски и разрешения могут быть предоставлены Заказчиком не позднее, чем за 7 (семь) календарных дней до запланированной даты начала оказания Услуг. 5.10. По запросу Заказчика Поставщик своевременно предоставит ему необходимую информацию, которая может потребоваться Заказчику для оформления разрешений. Все документально подтвержденные расходы и затраты, непосредственно связанные с любого рода задержками, возникающими по причине неполучения Поставщиком каких-либо требуемых разрешений, должны быть отнесены на счет и риск Заказчика. 5.11. Если Заказчик не выполняет условия, оговоренные в пунктах 5.9. и 9.1. Договора, Поставщик должен незамедлительно направить Заказчику письменное уведомление о факте задержки со стороны Заказчика и продлении срока оказания Услуг. После получения уведомления от Поставщика, Заказчик должен оценить ситуацию и продлить срок предоставления Услуг на срок задержки. 6. Упаковка и маркировка 6.1. Оборудование должно быть упаковано в надлежащую упаковку. Упаковка должна обеспечить сохранность Оборудования во время транспортировки соответствующим видом транспорта с завода - изготовителя до конечного пункта и во время хранения в складских помещениях. Упаковка должна соответствовать государственным стандартам, техническим условиям, другой нормативно-технической документации. Упаковка должна обеспечивать возможность ручной и механической погрузки (грузоподъемником). 6.2. Упаковка (тара) маркируется водостойкой краской на английском и русском языках несмываемой краской. Маркировка и штрих-кодировка должна быть четкой и включать следующие сведения: Заказчик; Грузополучатель; договор №______; изготовитель Оборудования; количество единиц Оборудования; товарный знак; условное обозначение Оборудования; номер места (ящика, контейнера); вес нетто, вес брутто; размеры тары в см. (длина, высота, ширина); объект. 6.3. Маркировка может иметь также другие обозначения, наличие которых предполагается специфическим характером Оборудования или станции, где оно будет установлено. 6.4. Поставщик несет ответственность перед Заказчиком за все потери и/или неисправности, связанные с ненадежной упаковкой и неправильной маркировкой. 7. Уведомления, переписка 7.1. Любые уведомления или другая информация, которые должны быть переданы одной из Сторон другой Стороне, будут считаться действительно переданными, когда они будут 110 направлены по почте (предварительно оплаченным заказным письмом или по телеграфу), или по факсу, или телефаксу, или с курьером по следующим адресам: Уведомления, касающиеся отгрузки Оборудования, могут быть отправлены по электронной почте. Заказчик: 050020, г. Алматы, АО «АЛТЕЛ» ул. Достык 248Б Поставщик: -----8. Проверка поставки 8.1. Поставщик, согласно п. 2.1. Договора, не менее чем за 3 (три) календарных дня до начала отправки, информирует Заказчика по факсу о готовности Оборудования к отправке. 8.2. Проверка поставки Оборудования осуществляется представителями Заказчика совместно с представителем Поставщика в течение 3 (трёх) рабочих дней со дня прибытия Оборудования на объект установки, путем внешнего осмотра тары и маркировки на соответствие документам, указанным в пункте 5.6. Договора. 8.3. В случае обнаружения в поставленном Оборудовании недостатков, факта недопоставки или иных несоответствий условиям Договора, Заказчик уведомляет об этом Поставщика не позднее 3 (три) рабочих дней по факсу или иным средством связи и составляет акт с участием Поставщика. 8.4 Поставщик обязуется в течение 3 (трёх) рабочих дней принять решение по факту ненадлежащей поставки и сообщить о нем Заказчику. При этом Поставщик за свой счет обязуется не позднее 60 (шестьдесят) рабочих дней с момента получения уведомления от Заказчика произвести замену дефектного Оборудования или поставить недопоставленную часть Оборудования. 9. Монтаж 9.1. Заказчик по запросу Поставщика должен предоставить Поставщику все данные, нeобходимыe для оказания Услуг. За 10 (десять) календарных дней до даты поставки Оборудования Поставщик должен закончить подготовку производственных площадей, на которых будет монтироваться Оборудование. 9.2. Поставщик обязуется оказать Услуги в сроки, указанные в пункте 5.1. Договора, при условии, что: 9.2.1 Заказчик получил и предоставил до запланированной для начала предоставления Услуг даты все требующиеся разрешения, согласно пункту 5.9. Договора; 9.2.2 Срок окончания предоставления Услуг не был продлен по взаимному согласованию Сторон. 9.3. Поставщик несет полную ответственность за проектирование, монтаж, настройку, интегрирование, проведение измерений и тестов Оборудования в соответствии с техническими требованиями Заказчика при условии, что Заказчик выполнит свои обязательства согласно условиям Договора. 10. Порядок приемки 10.1. Выполнение Работ и оказание Услуг должны быть произведены в сроки согласно графику, приведенному в Приложении №4. 10.2. До предъявления Сети к приемо-сдаточным испытаниям Поставщик обязан предоставить Заказчику сертификаты соответствия безопасности (качеству) Республики Казахстан на установленное Оборудование, а также проектную документацию в объеме согласно (Приложение№2) и Протоколы поверки монтажа Оборудования на объектах Сети. 111 10.3. Приемо-сдаточные испытания Сети будут проводиться после завершения монтажа, настройки Оборудования, интегрирования всех систем Сети и проведения оценок / измерений KPI по методикам, согласованным Сторонами (Приложение №2 к Договору). По результатам приемо-сдаточных испытаний Сети Стороны подпишут Акт предварительной приемки (PAC) с обязательным приложением к нему перечня замечаний / выявленных несоответствий, а также сроков их исправления. В случае несоответствия KPI Сети требованиям Заказчика, Поставщик обязан за свой счет провести комплекс дополнительных работ на Сети, включая, в случае необходимости, поставку и установку дополнительного оборудования, а также разработку проектной документации. 10.4 Приемо-сдаточные испытания включают в себя следующие этапы: 10.4.1. Приемка строительно-монтажных работ. Проводится по каждому объекту. (Проверяется наличие всей необходимой проектной документации с учетом технологической части по количеству и плану размещения оборудования на объекте, качество строительных и монтажных работ и соответствие проектной документации и т.д. Стороны составят и согласуют форму Акта приемки и “Check List”). Подписывается соответствующий Акт приемки строительно-монтажных работ с указанием Перечня выявленных недостатков и сроков их устранения. При необходимости составляется дефектный Акт по неисправному оборудованию. 10.4.2. Приемка работ по настройке и интеграции оборудования в сеть. Проводится по каждому объекту сети (по всем объектам базовых станций и узлам EPC). К моменту приемки Поставщик должен обеспечить включение (“power on”) оборудования, проведение рутинных тестов аппаратного обеспечения (для узлов EPC каждого модуля отдельно и системы в целом); обеспечить отсутствие на оборудовании сообщений об ошибках аппаратного обеспечения (“Faulty modules free”); интеграцию оборудования в сеть Заказчика; 10.4.3. Для оборудования центральных узлов сети процедура тестирования должна также влкючать проверку базового и опционального функционала оборудования в соответствии с техническими требованиями Заказчика и требования стандратов 3GPP по сетям LTE. 10.4.4. Стороны согласуют и утвердят состав тестов и форму Протокола тестирования. Поставщик несет ответственность за проведение тестирования, подготовку Протоколов тестирования. Заказчик имеет право принять участие в проведении тестов, осуществляет приемку и подписание Актов приемки работ по настройке и интеграции каждого элемента сети. 10.4.5. Приемка кластеров сети и в целом сети на соответствие заданным показателям качества KPI. Проводится по мере готовности по каждому кластеру сети радиодоступа (5-15 сайтов базовых станций, географически образующих единую зону), так и в целом по сети (возможно по каждому городу отдельно). При условии успешного тестирования всех кластеров сети Стороны подпишут Акт предварительной приемки сети с указанием Перечня выявленных недостатков/несоответствий для устранения и сроков устранения. Заказчик имеет право принятия решения о возможности подписания Акта предварительной приемки в зависимости от серьезности выявленных недостатков и несоответствий требуемым KPI. В случае несоответствия измеренных KPI Сети требованиям Заказчика, Поставщик обязан за свой счет провести комплекс дополнительных работ, включая, в случае необходимости, поставку и установку дополнительного оборудования (с полным комплексом работ, связвнных с установкой дополнительного оборудования), провести работы по повторной оптимизации и настройке сети, обеспечить повторное тестирование и сдачу Сети Заказчику. 10.5. Период тестовой эксплуатации Сети составляет 90 календарных дней. Датой ввода Сети в тестовую эксплуатацию и начала исчисления гарантийного периода будет считаться дата подписания Сторонами соответствующего Акта предварительной приемки (PAC). Заказчик имеет право начать пропуск коммерческого трафика в период тестовой эксплуатации сети. Начало пропуска коммерческого трафика не должно приводить к обязательному подписанию Акта окончательной приемки сети. 10.6. В период тестовой эксплуатации Сети Поставщик обязан устранить зафиксированные в РАС замечания и завершить работы по оптимизацию радиосети. 10.7. По завершению периода тестовой эксплуатации и при условии устранения всех 112 замечаний, указанных в Акте предварительной приемке, Сторонами подписывается Акт окончательной приемки Сети, который свидетельствует о выполнении всех условий и обязательств по Договору со стороны Поставщика, включая передачу Заказчику проектной документации в полном объеме, ЗИП и дополнительного объема оборудования, поставленного согласно п.10.3. 10.8. Если в течение 30 (тридцать) календарных дней после истечения срока тестовой эксплуатации и уведомления Поставщиком об устранении замечаний Поставщик не получает подписанный Акт окончательной приемки или письменно обоснованное объяснение Заказчика об отказе от окончательной приемки, то Акт окончательной приемки, подписанный Поставщиком в одностороннем порядке, признается действительным. 11. Гарантии. Качество. Рекламации 11.1. Поставщик гарантирует высокое качество поставляемого Оборудования, материалов и комплектующих изделий, а также качество производственной технологии, отвечающей современным мировым стандартам и нормам. Качество поставляемой продукции подтверждается сертификатом соответствия безопасности (качеству), а количество и номенклатура поставки должна соответствовать Спецификациям, указанным в Приложении № 1 к Договору. 11.2. Гарантийный срок на поставленное Оборудование, выполненные работы и оказанные Услуги составляет 24 (двадцать четыре) месяца с момента подписания Акта предварительной приемки Оборудования в эксплуатацию при условии соблюдения требований, указанных в технической документации на Оборудование, предписаний Поставщика, а также стандартных норм и правил на поставляемое Оборудование, за исключением дефектов, возникших в результате форс-мажорных обстоятельств. Если в течение гарантийного периода будут выявлены дефекты Оборудования или его несоответствие условиям Договора, Поставщик за свой счет обязуется отремонтировать или заменить дефектное Оборудование на новое в срок не более 45 (сорок пять) календарных дней с момента отправки на ремонт. В случае замены вышедшего из строя блока во время гарантийного периода, срок гарантийного периода на данный блок продлевается с момента получения замененного блока на склад Заказчика. Все расходы по ремонту или замене дефектного Оборудования, в том числе связанные с таможенной очисткой и транспортировкой, несет Поставщик. 11.3. Гарантия распространяется на все поставленное оборудование и программное обеспечение (ПО), включая оборудование и ПО третьих сторон. 11.4.. Гарантия не распространяется на дефекты, вызванные неправильной эксплуатацией или несанкционированным использованием Оборудования третьей стороной. 11.5. Претензия (рекламация) по вопросам качества и количества поставленного Оборудования предъявляется Заказчиком к Поставщику: по количеству - не позднее 30 (тридцать) календарных дней с даты поставки Оборудования; по качеству – в течение гарантийного периода. Поставщик обязан рассмотреть претензию (рекламацию) Заказчика в течение 5 (пять) рабочих дней с момента ее получения. Если Поставщик не дал ответа в названный срок, такая претензия считается признанной Поставщиком. 11.6. Заказчик несет ответственность за таможенное оформление при вывозе на ремонт дефектных частей, а так же при ввозе с ремонта. 11.7. Все расходы, связанные с гарантийным обслуживанием, несет Поставщик, за исключением случаев, предусмотренных пунктами 11.3. Договора. 11.8 Поставщик гарантирует, что все заменяемые компоненты, необходимые при техническом обслуживании оборудования, будут поставляться Заказчику на протяжении как минимум 10 лет с момента сдачи Сети в эксплуатацию. 11.9. Поставщик гарантирует, что в поставку включен ЗИП, обеспечивающий необходимый резерв запасных частей наибольшего спроса. Номенклатурный перечень и количественный состав ЗИП соответствует перечню, рекомендованному Поставщиком для первых двух лет 113 эксплуатации Сети. 11.10. Условия поддержки и обслуживания, а также ремонта Оборудования по истечению гарантийного периода будут определены в отдельном соглашении Сторон. При этом Поставщик гарантирует, что годовая стоимость для максимального уровня послегарантийной поддержки, оказываемой центром поддержки Поставщика, не превысит 7 (семь) % от стоимости поставленного по настоящему Договору основного технологического оборудования и ПО (не включая стоимость пассивного оборудования и материалов, а также стоимость услуг по монтажу и настройке). 12. Ответственность сторон 12.1. В случае нарушения Поставщиком срока поставки Оборудования и оказания Услуг, установленного пунктом 5.1. и при выполнении Заказчиком условий, описанных в пунктах 9.1., 9.2., 9.3. Договора, Заказчик вправе потребовать, а Поставщик в этом случае должен оплатить Заказчику пеню в размере 0,1% от общей стоимости Договора за каждый день просрочки, но не более 10% от общей стоимости Договора. 12.2. Если поставленное Оборудование не соответствует по качеству стандартам, иной документации или условиям Договора, а также, если поставлено некомплектное Оборудование, Поставщик меняет его или доукомплектовывает на Оборудование надлежащего качества. Неисправное Оборудование должно быть восстановлено и возвращено Поставщиком в течение 60 (шестьдесят) календарных дней с момента предъявления Заказчиком соответствующих требований. Если Оборудование не будет возвращено в течение этого срока, Заказчик вправе потребовать, а Поставщик в этом случае будет обязан уплатить штрафные санкции в размере 0,1% от стоимости неисправного Оборудования за каждый день просрочки, но не более 5% от стоимости неисправного Оборудования.. Если Поставщик в установленный Сторонами срок устранил дефекты в Оборудовании или доукомплектовал его, штрафы, предусмотренные настоящим пунктом, не взимаются. 12.3. При несвоевременной оплате Оборудования и/или Услуг, Поставщик вправе потребовать, а Заказчик в этом случае должен будет заплатить Поставщику пеню в размере 0,1 % от суммы просроченного платежа за каждый день просрочки, но не более 10% от суммы просроченного платежа. Действие этого пункта на предоплату не распространяется. 12.4. Уплата неустоек и штрафов не является основанием для освобождения Сторон от обязательств по Договору. Уплата неустоек и штрафов осуществляется Сторонами в течение 20 (двадцати) банковских дней с даты получения соответствующего уведомления. 12.5 Независимо от каких-либо положений Договора, ни одна из Сторон не несет ответственности перед другой Стороной или какой-либо третьей стороной за какие-либо косвенные, случайные или побочные убытки, включая потерю прибыли или упущенную выгоду. Общая ответственность, которую несет Исполнитель по возмещению убытков, упомянутых в настоящем Договоре, ограничивается суммой причиненного реального ущерба (утрата или повреждение имущества). 13. Форс-мажорные обстоятельства 13.1. Ни одна из Сторон не несет ответственности перед другой Стороной за невыполнение обязательств по Договору, возникших помимо воли и желания Сторон которые нельзя предвидеть или избежать, включая объявленную или фактическую войну, гражданские волнения, эпидемии, блокаду, эмбарго, землетрясения, наводнения, пожары и другие стихийные бедствия. 13.2. Свидетельство, выданное компетентным государственным органом, является достаточным подтверждением наличия и продолжительности действия непреодолимой силы. 13.3. Сторона, для которой стало невозможным выполнение своих обязательств по Договору должна дать извещение другой Стороне в течение 7 (семь) рабочих дней о начале и прекращении действия обстоятельств, воспрепятствовавших выполнению обязательств по Договору. В случае несвоевременного извещения о наступлении форс-мажорных обстоятельств, соответствующая Сторона лишается права освобождения от обязательств по 114 Договору. 13.4. Если обстоятельства непреодолимой силы действуют на протяжении 3-х последовательных месяцев и не обнаруживают признаков прекращения, Договор может быть расторгнут любой из Сторон путем направления уведомления другой Стороне. 14. Срок действия Договора 14.1. Договор вступает в силу в день его подписания Сторонами и действует до полного исполнения Сторонами своих обязательств по Договору. 15. Расторжение Договора в одностороннем порядке 15.1. Заказчик вправе в одностороннем порядке расторгнуть Договор путем направления другой Стороне письменного уведомления за 20 (двадцать) рабочих дней до даты расторжения в случаях: поставки Оборудования ненадлежащего качества с недостатками, которые не могут быть устранены в приемлемый для Заказчика срок; - не поставки Оборудования или не оказания Услуг в срок свыше 30 (тридцать) календарных дней с момента, указанного в пункте 5.1. Договора. 15.2. Поставщик вправе в одностороннем порядке расторгнуть Договор в случае: - нарушения Заказчиком сроков оплаты более чем на 30 (тридцать) календарных дней по сравнению со сроками, установленными в Договоре. 16. Техническая поддержка и ремонт 16.1. Поставщик должен предоставить Заказчику услуги по технической поддержке на весь период эксплуатации поставленного Оборудования. Услуги по технической поддержке заключаются в полном устранении неисправности и приведении Оборудования в состояние, имевшее место до аварии. По окончании гарантийного срока, услуги по технической поддержке и послегарантийному обслуживанию будут оказаны Заказчику на основе отдельного договора, заключаемого в рамках соглашения Сторон, законодательства Республики Казахстан и/или внутренних актов Заказчика, регламентирующих порядок осуществления закупок. 17. Разрешение споров 17.1. В случае возникновения споров и разногласий по Договору, Стороны обязуются принять все меры к их урегулированию путем переговоров. 17.2. В случае невозможности разрешения споров и разногласий путем переговоров между Сторонами, то они подлежат разрешению в судебном порядке, в соответствии с законодательством Республики Казахстан. 17.3. Применимым правом является право Республики Казахстан. Спорные вопросы, возникшие в ходе исполнения Договора, рассматриваются судами Республики Казахстан в соответствии с законодательством Республики Казахстан и на территории Республики Казахстан. 18. Программное обеспечение 18.1. Заказчик настоящим дает безусловное согласие на то, что Договор не предоставляет ему никаких прав на Программное Обеспечение, являющееся неотъемлемой частью поставляемого ему Оборудования (или каким-либо иным способом предоставляемое ему в рамках Договора), кроме как приведенных в настоящем разделе 18 Договора: 18.1.1. Поскольку поставляемое Оборудование содержит в качестве своей неотъемлемой части Программное Обеспечение, необходимое для обычного использования Оборудования и неотделимое от него без утраты Оборудованием своих функций, то в результате приобретения Заказчиком Оборудования по Договору Поставщик предоставляет Заказчику неисключительное, непередаваемое право на использование Программного Обеспечения, применяемого в Оборудовании, с единственной целью использования Оборудования согласно Договора. 115 18.1.2. Программное Обеспечение остается собственностью Поставщика и без письменного разрешения Поставщика не может передаваться, сообщаться или другим образом разглашаться Заказчиком третьей стороне. 18.1.3. Заказчику не разрешается копировать, изменять, дополнять, декомпилировать, подвергать инженерному анализу, разбирать или подделывать поставленное Программное Обеспечение без предварительного письменного согласия Поставщика. Программное Обеспечение может копироваться лишь в эксплуатационных нуждах или в целях, на которые получено четкое письменное разрешение от Поставщика. 18.1.4. Заказчику не разрешается без письменного разрешения Поставщика удалять, отменять или изменять любое коммерческое название Поставщика, торговую марку, торговый знак, логотип, сервисные марки, символы или коды из Программного обеспечения. 18.2. Обязательство по защите интеллектуальных прав Поставщика на Программное Обеспечение, как это определено в пункте 18.1. Договора, продолжает быть в силе и после истечения срока действия или расторжения Договора, в не зависимости от причины такого расторжения. 18.3. Поставщик может периодически выпускать новые версии по поддержке текущей эксплуатации Программного Обеспечения, или усовершенствованные версии Программного Обеспечения. Изменения, вносимые в Программное Обеспечение для корректировки ошибок, предоставляются Заказчику бесплатно. Изменения, связанные с добавлением новых особенностей Программного Обеспечения, предоставляются Заказчику на платной основе согласно отдельному соглашению Сторон. 19. Возмещение ущерба в отношении прав на интеллектуальную собственность 19.1. Поставщик, в рамках правил, предусмотренных в разделе 12 Договора, гарантирует Заказчику возмещение расходов и издержек, понесенных Заказчиком в случае, если предъявлен иск третьей стороной против Заказчика на том основании, что Оборудование (или какая-либо его часть), поставленное в рамках Договора, нарушает патентные, авторские или иные права интеллектуальной собственности какой-либо третьей стороны, но только при условии, что: a) Заказчик незамедлительно (и не позднее чем, в течение 30 (Тридцати) календарных дней с момента обнаружения информации о предъявлении иска и/или о намерении его предъявить) известит Поставщика в письменной форме о возникновении любого иска, предъявленного Заказчику, или о предполагаемом предъявлении иска против Заказчика и/или Поставщика, касающегося прав интеллектуальной собственности, относящихся к Договору; и b) Заказчик предоставит Поставщику необходимые полномочия, всю информацию и любую помощь, необходимые Поставщику для защиты и/или проведения согласовательных процедур в отношении любого такового иска; и c) Заказчик обязуется воздерживаться от каких-либо признаний или заявлений и не подвергать риску защиту иска каким-либо иным способом без получения на то предварительного письменного согласия Поставщика. 19.2. Ответственность, указанная в пункте 19.1. Договора, должна во всех случаях быть ограничена тем размером возмещаемых убытков, который будет определен окончательным решением правомочного суда или какой-либо внесудебной (включая согласовательную) процедуры. 19.3. Если в результате претензий, перечисленных в пункте 19.1. Договора, запрещается продажа, импорт или использование какого-либо элемента Оборудования, Поставщик имеет право по своему выбору и усмотрению: a) обсудить лицензионное или другое соглашение с предъявителем претензии так, чтобы элементы Оборудования не нарушали интеллектуальных прав третьей стороны; либо, b) модифицировать за свой счет такие элементы так, чтобы они не нарушали интеллектуальных прав третьей стороны. 19.3.1. Если выполнение подпунктов а) и b) пункта 19.3. Договора по каким-либо причинам невозможно, то Поставщик обязуется принять возврат Оборудования, элементы которого нарушают какие-либо интеллектуальные права, и возместить Заказчику остаточную стоимость вышеуказанного Оборудования, исчисляемую в соответствии с законодательством Республики 116 Казахстан, действующим на дату такового исчисления, и сумму прямых убытков, понесенных Заказчиком в результате такого возврата. 19.4. Поставщик не несет никакой ответственности, если иск или претензия о том, что Оборудование или его элементы нарушают какие-либо интеллектуальные права, если такой иск или претензия, в целом или частично, вызваны, основаны или является результатом: a) любого изменения и/или модификации Оборудования Заказчиком или какой-либо третьей стороной, без письменного разрешения на то Поставщика; b) использования элементов Оборудования, поставленных Поставщиком, в комбинации или соединении с любыми другими элементами, не поставляемыми или не производимыми Поставщиком и/или его Аффилированными лицами. 20. Прочие условия 20.1. Изменения и дополнения к Договору, не противоречащие законодательству Республики Казахстан, имеют юридическую силу только в том случае, если они совершены в письменной форме и подписаны уполномоченными представителями Сторон. 20.2. Ни одна из Сторон Договора не может переуступать или передавать любые и/или все свои права либо обязательства третьей стороне без предварительного получения письменного согласия другой Стороны. Поставщик имеет право с письменного согласия Заказчика нанять субподрядчиков, при условии предоставления Заказчику Договора субподряда, либо подписания Соглашения о передаче прав и обязательств. Наличие субподрядчиков не освобождает Поставщика от любых его обязательств или обязанностей по Договору. Поставщик гарантирует должный уровень профессионализма субподрядчиков. Такие отношения субподряда ни в коей мере не меняют сущность этого Договора на условиях «под ключ», а также не освобождают Поставщика от его обязательств по Договору относительно полной ответственности за установку и сдачу в эксплуатацию всего Оборудования. В рамках Договора Поставщик остается единственным партнером Заказчика. 20.3. Ни одна из Сторон не должна без предварительного письменного согласия другой Стороны раскрывать кому-либо содержание настоящего Договора или какого-либо из его положений, а также содержание технической документации, планов, чертежей, моделей, образцов или другой информации, связанных с заключением или исполнением настоящего Договора, за исключением того персонала, который привлечен для выполнения настоящего Договора. Указанные документы и/или информация будут использоваться Сторонами конфиденциально и исключительно в той мере, насколько это необходимо для выполнения договорных обязательств. 20.4. Приложения к Договору, подписанные уполномоченными представителями Сторон, являются его неотъемлемой частью Договора. 20.5. Настоящий Договор подписан на русском и английском языках в трех экземплярах, имеющих равную юридическую силу, один экземпляр Поставщику и два экземпляра Заказчику. При рассмотрении споров между Сторонами версия Договора на русском языке имеет приоритет перед английской версией. 21.Юридические адреса, банковские реквизиты «Сторон» Юридический адрес Заказчика АО «АЛТЕЛ» 050057, г. Алматы, ул. Жарокова, 189 Почтовый адрес: 050020, г. Алматы, пр.Достык 248Б тел. (727) 259-81-20, факс: 259-81-21 Банковские реквизиты Заказчика: АО “Алтел ” Kazkommertsbank, 117 Almaty, Kazakhstan БИК KZKOKZKX , КБе 17, КНП 852, БИН 940140000206 РНН 600600021605, IBAN (Р/С) KZ829261802100509000 (для платежей в KZT) IBAN (Р/С) KZ559261802100509001 (для платежей в USD) Юридический адрес Поставщика: ---Банковские реквизиты Поставщика: - ЗАКАЗЧИК: ПОСТАВЩИК: __________________________ (Подпись; Печать) _________________________ (Подпись; Печать) ----- Сауранбеков «АЛТЕЛ» М.Т. – Президент Дата: ____________________ АО Дата: _____________________________ 118 Приложение 1 к Договору о закупках товаров и услуг №__________/ _________201__ СПЕЦИФИКАЦИЯ Оборудования и Услуг Стоймость оборудования № Регион (полный юр.адрес) ЗАКАЗЧИК: Оборудование ПО и лицензии Доставка и страхование Стоимость оборудования на Инженерные условиях услуги DAP/DDP Итоговая стоимость проекта на условиях DAP/DDP ПОСТАВЩИК: 119 __________________________ (Подпись; Печать) Сауранбеков «АЛТЕЛ» М.Т. – Президент АО _________________________ (Подпись; Печать) ---- Дата: ____________________ 120 Приложение №2 к Договору о закупках _____ №__________ /от ______ ___________ 201___г Техническое задание на построение сети ЗАКАЗЧИК: __________________________ (Подпись; Печать) Сауранбеков М.Т. – Президент АО «АЛТЕЛ» Дата: ____________________ 121 Приложение №3 к Договору о закупках _____ №__________ /от ______ ___________ 201___г Распределение обязанностей по установке и материалам Распределение обязанностей при поставкеоборудования No. (№) Ответственность по поставке Наименование Поставщик Заказчик 1.1 1.2 Распределение материалов при поставкематериалов No. (№) Наименование Ответственность по поставке Поставщик Заказчик 1.1 1.2 … No. (№) Распределение обязанностей по установке Ответственность по установке Наименование Поставщик Заказчик 1.1 1.2 … ЗАКАЗЧИК: ПОСТАВЩИК: __________________________ Подпись; Печать _________________________ Подпись; Печать ---- Сауранбеков М.Т. – Президент АО «АЛТЕЛ» Дата: ____________________ Дата: _____________________________ 122 Приложение №4 к Договору о закупках _________ №______ / от ______ ___________ 201__г ГРАФИК PЕАЛИЗАЦИИ ДОГОВОРА № Задача 1 2 3 4 5 6 7 8 9 10 11 Прод-ность, недель 201__ год 1 2 3 4 5 6 7 8 9 Подписание договора Выбор и Обследование Предоплата Производство Доставка Таможенная чистка Инсталляция Испытания и тестирование Первичная приёмка Окончательная приёмка Завершение ЗАКАЗЧИК: ПОСТАВЩИК: __________________________ (Подпись; Печать) _________________________ (Подпись; Печать) --Дата:___________________________ Сауранбеков М.Т. – Президент АО «АЛТЕЛ» Дата: ____________________ 123 Приложение №5 к Договору о закупках ________ №_______ / от ______ ___________ 2011г Форма акта приема-передачи Оборудования Место приемки Дата ________ Акционерное общество «АЛТЕЛ» как «Заказчик», в лице _______________________, с одной стороны, и ________________ как «Поставщик», в лице____________________, с другой стороны, составили настоящий Акт о нижеследующем: 1. В соответствии с условиями Договора ___________ от «_____» _________2011 г. Поставщик передает, а Заказчик принимает следующее Оборудование: # Код Описание оборудования Кол-во Серийный номер Цена Сумма 1. Стоимость оборудования составляет ________ (________________) долларов США. 2. Претензии по комплектности и внешнему виду поставленного Поставщиком по Договору Оборудованию, стоимость поврежденного или недопоставленного Оборудования и сроки устранения претензий Поставщиком приведены ниже: № Существо претензии Срок устранения Стоимость недопоставленного или поврежденного Оборудования ЗАКАЗЧИК: ПОСТАВЩИК: __________________________ (Подпись; Печать) _________________________ (Подпись; Печать) --Дата: _________________________ Сауранбеков М.Т. – Президент АО «АЛТЕЛ» Дата: ____________________ Приложение №6 к Договору о закупках ________ №________ / от ______ ___________ 2011г Форма акта приемки-сдачи оказанных услуг Дата: __________ Место приемки __________ Мы, нижеподписавшиеся представители АО «Алтел», как «Заказчикя» в лице ________________________, и __________________, как «Поставщик» в лице ____________________., составили настоящий Акт о том, что «Поставщиком» с _________________2011г. по _________ 2012г. оказаны согласованные Услуги, в соответствии с Договором №_____ от «_____»__________2011г., в следующем объёме: Регион, объект ... Выполненные услуги … Сумма, НДС … Всего, … Номер заказа в SAP … … … … … … Итого: Выполненные «Поставщиком» услуги на территории _______________________________ соответствуют требованиям «Заказчикя» и удовлетворяют условиям Договора. Стоимость выполненных Услуг составляет __________________________ (______________) Услуги приняты От «Поставщика»: ЗАКАЗЧИКЬ: Услуги оказаны От «Заказчикя»: ПОСТАВЩИК: 125 _____________________ (Подпись; Печать) Сауранбеков М.Т. – Президент АО «Алтел» Дата: ____________________ _________________________ (Подпись; Печать) ---Дата: _____________________________ 126
