Я думаю эта ссылка довольно неплохо объясняет это.
Открытая проблема терминала возникает, когда два узла (в данном случае B & C) вызывают чрезмерные задержки друг в друге из-за включения механизмов (например, предотвращение столкновений на основе несущей, схемы RTS / CTS), чтобы избежать скрытого узла проблема. Это является результатом компромисса, сделанного для улучшения производительности в ситуации со скрытыми узлами.
Как упоминается в ссылке, существуют методы (например, направленные антенны), которые могут помочь уменьшить эти задержки (однако, я бы сказал, что использование направленных антенн на самом деле больше похоже на изоляцию обеих систем, но не решает эту проблему) .
Вы можете испытать искушение взглянуть на эту ситуацию с помощью B & C и сделать вывод «ну, я знаю, что они не будут вмешиваться, они просто должны все равно отправлять!» Но вы также должны учитывать, что большинство беспроводные системы используют подтверждения и т. д. для проверки получения данных, что также может повлиять на этот выбор. Например, давайте рассмотрим сценарий, в котором B & C игнорирует занятый канал:
- B имеет длинный пакет для отправки в A, проверяет, свободен ли воздух, и начинает отправку
- C имеет короткий пакет для отправки на D, проверяет эфир, игнорирует его занятость и все равно начинает отправку
- C заканчивает отправку, D немедленно отправляет ACK обратно на C
- B все еще отправляет свой пакет, поэтому C никогда не слышит ACK от D, так как B мешает ему
- C решает начать отправку снова
- B заканчивается, A отправляет ACK обратно на B
- C все еще отправляет свой пакет (второй раз), поэтому B никогда не слышит ACK от A
- И это песня, которая никогда не заканчивается ...