В данной статье речь о балансировке нагрузки между MME
GUMMEI
Каждый MME в сети имеет свой уникальный идентификатор — GUMMEI (Globally Unique MME Identifier). GUMMEI состоит из следующих полей:
- MNC = Mobile Network Code — код сети оператора
- MCC = Mobile Country Code — код страны
- MMEGI = MME Group Identifier — идентификатор группы, которой принадлежит MME
- MMEC = MME Code — уникальный код MME
Соответственно, если все MME принадлежат одному оператору (MNC+MCC), то уникальным идентификатором каждого MME становится пара MMEGI+MMEC. MME Group (MMEG) — это группа MME, объединенных в пул. MMEC — это код MME внутри пула.
Load Weight Factor
Каждому MME также присваивается так называемый весовой коэффициент — Load Weight Factor.
После того, как eNodeB установит соединение с MME, он инициирует процедуру S1 Setup, во время которой MME сообщает eNodeB свой GUMMEI, а также Load Weight Factor. Этот коэффициент используется eNodeB для распределения нагрузки между несколькими MME в пуле. Например, eNodeB подключен к MME-1 (Load Weight Factor = 50, MMEGI=10, MMEC=1) и к MME-2 (Load Weight Factor=100, MMEGI=10, MMEC=2). При такой конфигурации, грубо говоря, 66,6% (2/3) процента запросов пойдут в MME-2, 33,3%(1/3) пойдет в MME-1.
Если, например, MME-2 выйдет из строя, то все запросы пойдут в MME-1. Таким образом достигаются резервирование и балансировка нагрузки между MME в пуле. Стоит отметить, что весовой коэффициент имеет смысл, когда MME объединены в пул, т.е имеют общий MMEGI и подключены друг к другу.
Одним из примеров использования весового коэффициента является добавление в пул нового MME. На первоначальном этапе такому MME присваивается самый высокий весовой коэффициент, чтобы большинство новых запросов шло на этот MME, что позволяет равномерно распределить нагрузку в пуле. Далее, в процессе эксплуатации весовые коэффициенты можно менять в зависимости от текущего состояния сети. После изменения весового коэффициента, MME генерирует специальное сообщение и отправляет его eNodeB.
Повторная балансировка
После того, как мобильная станция подключается к LTE сети, ей выделяется временный идентификатор — GUTI, который состоит из GUMMEI (идентификатора MME, который обслуживает данную станцию) и M-TMSI (временного уникального идентификатора самой мобильной станции). Этот GUMMEI мобильной станции присылает MME. Во всех последующих запросах мобильная станция вместо IMSI использует GUMMEI. Получив запрос от мобильной станции, eNodeB видит GUMMEI и отправляет запрос в соответствующий MME.
Возникает ситуация, когда в силу определенных причин нагрузка на один из MME в пуле резко возрастает. Чтобы избежать перегрузок, MME может инициировать процедуру повторной балансировки — Load Rebalancing. В чем она заключается?
MME шлет eNodeB сообщение UE Context Modification Request, в котором в поле Cause указывает "Load Balancing TAU Required". eNodeB, получив это сообщение, ретранслирует его мобильной станции, тем самым заставляя мобильную станцию заново инициировать процедуру подключения к сети. Однако, в этом случае мобильная станция в запросе уже не указывает GUMMEI. Когда такой запрос приходит на eNodeB, eNodeB не видит GUMMEI, тем самым полагая, что это новый абонент.
После этого eNodeB иницирует функцию выбора MME и подключает абонента к другому MME. Но в этом случае есть вероятность, что eNodeB опять подключит абонента к тому же MME. Этого не происходит, так как после получения UE Context Modification Request с Cause="Load Balancing TAU Required", eNodeB обнуляет Load Weight Factor для данного MME. Тем самым данный MME вообще не участвует в процессе балансировки.
Выполнять повторную балансировку надо очень аккуратно, так как она может привести к перегрузке других MME в пуле, а также других элементов сети. Если количество абонентов велико, что процедура повторной балансировки выполняется в несколько этапов.
Спасибо внимание!
Ссылки
ссылка на оригинал статьи http://habrahabr.ru/post/187364/
Добавить комментарий