PAP писал(а):
3) не у всех трубок, заявленных как EDGE, эта технология поддерживается в направлении uplink, а также под вопросом поддержка динамической смены схемы кодирования при ухудшении или улучшении качества сигнала в этом направлении (если она поддерживается сетью); также возможны ситуации, когда динамическая смена схемы кодирования не поддерживается и в направлении downlink, а также возможно, что для упрощения некоторые производители не реализуют в оборудовании поддержку высших схем кодирования EDGE (MCS-9,8,7 ит.п.) и т.д.
Смотря о каком производителе оборудования (трубка или операторское) идет речь. Эрикссон поддерживает EDGE полностью, не урезано. Динамическое изменение схемы кодирования поддерживается во всех направлениях (надо его только включить). Производители телефонов - а кто их знает. но даже если и поддерживает - в зависимости от самой трубки (от качества приемника, например) и не работать правильно с высшими схемами кодирования (в данных условиях, например, низкий уровень сигнала или помехи), переходя на низшие скорости там, где другая трубка нормально работает.
Хотя, если судить по скоростям - эджа там нет (30 кБит - это 2 тс на обычном GPRS) или сектор достаточно сильно нагружен.
PAP писал(а):
А теперь суть предположения:
Возможно Nokia более оптимально умеет перераспределять ресурсы между uplink и downlink во время передачи. Например, трубки класса 10 должны уметь работать как в конфигурации 4+1, так и 3+2, 2+2, 1+2. изначальная конфигурация назначается сетью, но трубка может влиять на переходы между конфигурациями.
Это - да, как вариант.
PAP писал(а):
Исследования показывают, что при скачивании файлов с помощью FTP, конфигурация 3+1 хуже, чем 2+2. объясняется это относительно большим объёмом трафика TCP-подтверждений принятых пакетов в направлении uplink. При этом в конфигурации 4+1 возможна значительная задержка, а то и вовсе отбрасывание пакетов подтверждения из-за переполнения буфера передачи в трубе. При этом может возрасти трафик в направлении downlink (сеть не дождалась подтверждения пакета и превышен размер окна) за счёт повторно передаваемых пакетов. Поэтому трубе необходимо уметь адаптироваться к таким условиям, т.е. гибко менять конфигурацию.
Возможно что ещё..
Можно почитать эти исследования? Или это на практике? Просто (на примере спутникового интернета) соотношение трафика uplink/downlink составляет примерно 7/100 (по форумам где-то так получается), т.е. 7%. Причем при скачивании файлов - исходящего трафика меньше, чем при чтении страниц. А 7% - это 16 кбит/сек для 236 кбит (4тс*MCS9), что легко достигается даже на 1 тс аплинка.
А вообще - если проблема настолько серьезная и саппорт ничего сказать не может - надо проводить тесты.
1) Тестовая БС - или специальная тестовая БС (но тогда нужны телефоны с нетмониторами, что-бы зацепиться за нее, а их маловато), или БС где-нибудь в деревне, где GPRS трафик равен 0, и всегда есть 4 тайм-слота для GPRS (свободных от голоса). Причем тайм-слоты под GPRS должны выделять динамически, а не быть выделенны фиксированно, тогда будет видно, сколько тс трубка занимает для себя.
2) Файл для скачивания большого объема как можно ближе к SGSN.
Ну и начинать тесты. Тогда можно будет посмотреть, какая скорость (так как других пользователей не будет - то тогда скорость будет максимальная), если будет сопоставима с 60 кбит/сек (если сектор без эджа) - значит, проблемы скорее всего, не в трубках, а при других тестах не везло.
Если скорость будет ниже - то тогда смотреть, сколько тс на секторе занято (тогда будет понятно, сколько тайм-слотов на uplink/downlink занимается), и сравнить с "эталоном" - нокией.
Если количество занятых тайм-слотов будет одиноковым, а скорость - сильно разной (учитывая, что других пользователей GPRS на секторе нет) - то тогда даже и не знаю, что смотреть, скорее всего - обращаться в Эрикссон.
Только предположение человека, знающего вопрос довольно поверхностно, не претендующее на полноту и точность.. 