1) Мы знаем GMT offset БС'ок (храним в базе) 2) Когда message center получает SMS для обработки и коммутации -- правим время согласно GMT БС получателя.
Re: Мысля такая: ...digisMarch 25 2007, 06:19:37 UTC
А мне казалось, что мы имеем 2 времени: 1) Время отсылки сообщения отправителем ("домашнее" время отправителя, проставляется центром обработки сети отправителя); 2) Время записи сообщения в телефон получателя (проставляется телефоном).
Re: Мысля такая: ..._adept_March 25 2007, 20:38:16 UTC
Когда абонент в роуминге, каким образом мы получим время в его текущем camping cell?
В какой момент предлагается править время на SMSC - в момент приема входящего SMS-а или в момент его передачи для доставки? Как избежать увеличения сигнального траффика в случае множественных попыток доставки?
Как быть, если получатель - абонент другой сети? Понадеемся, что чужой SMSC поправит время, или исправим сами? А если там исправят еще раз? :)
Ну, roaming это особый случай.poigeMarch 26 2007, 16:19:52 UTC
Насчёт момента правки -- а как удобнее. :)
> абонент другой сети
аналогично roaming. За всех всё правильно сделать не получится; хорошо, если хотя-бы внутри своей GSM-сети на несколько GMT offset'ов не будет "разночтений".
Re: Ну, roaming это особый случай._adept_March 27 2007, 14:00:57 UTC
А они будут.
Предложенное решение содержит одну архитектурную закавыку. Предлагается хранить и брать время с БС-ок, которые (ограничимся только СМС-ами, без звонков) участвуют исключительно в организации транспорта. Им пофиг, что и куда передается с мобилки. А СМС-центру пофиг, откуда пришел СМС.
Чтобы реализовать предложенное изменение, придется эти два уровня сети "срастить". Сразу усложнится интерфейс СМС-центр<->HLR (придется лазить за текущим location-ом абонента), усложнится интерфейс SMS-цент<->MSC (прием и маршрутизация запросов к BTS или BSC). Усложнятся процедуры приема и доставки SMS-ов. (Если мы не придумаем, как обозначать в SMS-е тот факт, что время уже "подправлено", то мы рискуем свигать его неограниченное кол-во раз). А с SMS-ками из роуминга будет вообще цирк.
Итого - куча проблем, и очень мелкий benefit. Вот поэтому до сих пор никто и не чешется :)
2) Когда message center получает SMS для обработки и коммутации -- правим время согласно GMT БС получателя.
-- это один из вариантов. Реален?
Reply
1) Время отсылки сообщения отправителем ("домашнее" время отправителя, проставляется центром обработки сети отправителя);
2) Время записи сообщения в телефон получателя (проставляется телефоном).
Reply
Reply
Reply
В какой момент предлагается править время на SMSC - в момент приема входящего SMS-а или в момент его передачи для доставки? Как избежать увеличения сигнального траффика в случае множественных попыток доставки?
Как быть, если получатель - абонент другой сети? Понадеемся, что чужой SMSC поправит время, или исправим сами? А если там исправят еще раз? :)
Reply
> абонент другой сети
аналогично roaming. За всех всё правильно сделать не получится; хорошо, если хотя-бы внутри своей GSM-сети на несколько GMT offset'ов не будет "разночтений".
Reply
Предложенное решение содержит одну архитектурную закавыку. Предлагается хранить и брать время с БС-ок, которые (ограничимся только СМС-ами, без звонков) участвуют исключительно в организации транспорта. Им пофиг, что и куда передается с мобилки. А СМС-центру пофиг, откуда пришел СМС.
Чтобы реализовать предложенное изменение, придется эти два уровня сети "срастить". Сразу усложнится интерфейс СМС-центр<->HLR (придется лазить за текущим location-ом абонента), усложнится интерфейс SMS-цент<->MSC (прием и маршрутизация запросов к BTS или BSC). Усложнятся процедуры приема и доставки SMS-ов. (Если мы не придумаем, как обозначать в SMS-е тот факт, что время уже "подправлено", то мы рискуем свигать его неограниченное кол-во раз). А с SMS-ками из роуминга будет вообще цирк.
Итого - куча проблем, и очень мелкий benefit. Вот поэтому до сих пор никто и не чешется :)
Reply
А что касается roaming -- хорошим тоном было бы конвертить timestamp в UTC перед отправкой SMS за пределы своей сети. :)
Reply
Reply
Leave a comment