אז מה זה Wi-Fi Calling ולמה לנו כאנשי תוכנה חופשית זה כה חשוב ?
מי שעוקב אחרי מה שהולך בתשתיות יכול להיות ששם לב שחברות סלולאר שרוצות להוזיל עלויות ולהגדיל פריסה מחפשות פתרונות חדשים. חלק מהפתרונות שלהם הוא מעבר לשימוש ב
Offloading מסוגים שונים בין אם זה תחת
VoLTE ובין אם זה תחת VoWiFi.
הרעיון אומר שרכיב התקשורת שלכם (UE) מתחבר לרשת הוי-פי ומשתמש בה כרכיב גישת הרדיו שלה. הדבר מאפשר למכשירי הקצה לקבל תמיכה ברכבות , תעלות, בנייני משרדים וכל מיני מקומות בהם כיסוי הרדיו הרגיל מתקשה ודורש התקנת רכיבים אחרים (GSM-R ברכבות , משדרים מיוחדים בנקודות גישה וכו').
דרישות הבסיס לטכנולגיה נמצאת בצד לקוחות הקצה כבר שנים,איפונים (מעל 5) ואנדרויידים (4 ומעלה) אמורים לתמוך מהקופסה.
הדבר היחיד שאינו ממוש כמו שצריך ברכיבי הסלולאר הוא לקוח ה ipsec שיתאים בצורה טובה לדרישות ה VoWiFi.
השוני העיקר עבורנו המשתמשים של VoWi-Fi (או VoWiFi) מ VoLTE הוא הרמה בה מתחברים לרשת, לנו כלקוחות קצה קל יותר להשתמש ב VoWiFi בגלל הגישה בה כל לקוח (תאורתית) יוכל להפעיל נתב שמאפשר לטלפון הסלולארי שלו להתחבר לרשת במידה וספק השירות אישר את השיטה.
נניח ואתם חברת תקשורת שאין לה מספיק אנטנות אבל היא כן רוצה לפרוס תמיכה טובה מספיק או רשת אליה הלקוחות שלה יוכלו להתחבר, החברה יכולה לבחור לפרוס AP משלה או להשתמש בצד שלישי בשביל לספק את זה. למעשה זו אחת הסיבות בגללה חברות מפעילות תמיכה בטכנולוגיות, כמובן פרט לעובדה הקטנה שזה מוריד עלויות Roaming ושיחות בין לאומיות ומאפשר התמודדות מול שירותי OTT כמו skype.
מה שאותי מאוד מפתיע אותי זה שהשירות לא אומץ בצורה רחבה ע"י חברות כמו כמו גולן טלקום , פלאפון וסלקום.
אז איך זה עובד ?
לרעיון שימוש ב WiFi כרכיב התעבורה היו מספר גילגולים, הנושא הוצג גם ע"י GSMA וגם קיימים RFCים בדבר.
בגרסאות הישנות של הפתרון (לדוגמה ב WISPr) היו מגדירים שהטלפון שלכם יתחבר לרשתות בהם ה SSID הוא קבוע מראש (לדוגמה T-Mobile או tmobile) ואז מבצעים אימות EAP-SIM ומתקשרים ע"י SIP-IMS.
לאחר מספר גילגולים עברו לשימוש של גילוי דינאמי וקבלת הגדרות בזמן אמת ואז חיבור באמצעות רכיבי ה SIP ישירות לשרת (ספק השירות).שימוש בשירותי XCAP ועידכון מאפייני שיחה ע"י פעולות SIP.
ה
RFCים מדברים על שלושה גישות :
גישת ה Trusted - בה אנו סומכים על הרשת המארחת (שלנו ), במצב כזה חברת השירות היא בעלת תשתיות ה AP. היא מבצעת את האימות קרוב לנתבים (היא גם יכולה לספק שירותי ANDSQ בשביל לגרום למערכת להתחבר בצורה פשוטה יותר).
+-------+
| IMS |
| Core |
+-------------+ +-----------+ +-------+
| | | | |
| +--------+ | Flow mapped | | |
| |IMS APN | | to VMAC-01 | | +-------+
| | +-----------------+ | |IMS APN|
| |Client | | | +-------+ P-GW |
| +--------+ | | | +-------+
| | | |
| | |Release 12 |
| | | TWAG |
| | | | +-------+
| | | | |Default|
| | | +-------+ APN |
| +--------+ | Flow mapped | | | P-GW |
| |Default | | to VMAC-02 | | +-------+
| | APN +-----------------+ | |
| |Client | | | | |
| +--------+ | | | |
+-------------+ +-----------+ |
XXXXXX
XX XXX
XX XX
X X
X X
X Internet X
X X
X XX
X XX
XX XXXX
XXXXXX
גישה בה אנו לא סומכים על הרשת המארחת, בגישה זו חברת הסלולאר מאפשר להשתמש בשירותיה לאחר שניתן לפתוח ערוץ מאובטח לשירותי הרשת. לדוגמה ניתן יהיה להתחבר לשירותי רשת הסלולאר ע"ג רשתות ההויפי הציבוריות הפרוסות ברחוב או אפ לאשר למשתמשי קצה להשתמש ב WiFi הביתי שלהם.
+--------------+ +----------+ +-------+
| +----------+ | IMS-APN | | | |
| | SWu | | Traffic | | | |
| | Client +------------------------------------+ |
| | | | Other APN | | | ePDG |
| | | | traffic | | | |
| | +------------------------------------+ |
| | | | | | +-------+
| +----------+ | | | | |
| | | | S2b| |S2b
| UE | | WLAN | | +---+
| | | Access | | |
| +----------+ | LBO | | +-------+ +-------+
| | Native | | Traffic | | |IMS APN| | Other |
| | | | | | | PGW | | APN |
| | Client +-------------------+ | | | | PGW |
| | | | | | | +-------+ +-------+
| +----------+ | | | | | |
+--------------+ +----------+ | |
| | |
| +-------+ +-------+
| | IMS | | App |
| | | | Server|
v +-------+ +-------+
וגישה היברידת המשלבת את שני הדברים:
+------+ +---------+
| IMS | | Other |
| Core | |Services |
+------+ +---------+
| |
+------+ +-------+
+--------------+ +-----------+ |IMS | | Other |
| +----------+ | | | |P-GW | | P-GW |
| | SWu | | | +-------+ | +------+ +-------+
| | Client | | | |SIPTO | | | |
| | | | | ++NAT | | | +--------+
| +----------+ | | +-------+ | | |
| | | | +------+
| UE +------+ TWAG | S2b | ePDG |
| | | +--------+ |
| +----------+ | | | +------+
| | Native | | | |
| | Client | | | |
| | | | | | S2a +-------+
| +----------+ | | +--------+Default|
+--------------+ +-----------+ | PGW |
+-------+
|
|
+
XXXXXXXX
XX XX
X X
XInternetX
X X
XX XX
XXXXXXX
בגישה בה אנו לא סומכים על הרשת המארחת, מאפשרת ללקוח קצה להתחבר למשאבי הרשת אפילו דרך הנתב הביתי שלו.
בצורה כזאת חברות שמספקות MVNO (או ספקי תקשורת רגילים) יכולות להצהיר על הרשת שלהם תחת כתובות DNS, שמות השירותים מוגדרים מראש (כמו במקרה
הENUM ).
GSMA הכריז על מספר שירותים אליהם ניתן להתחבר בשביל לקבל גישה לשירותים :
כל אחת מהכתובת בעת משמעות משלה שמאפשרת שימוש במשאבים נוספים.
במהלך החיבור יקבל את המאפיינים של ה Evolved Packet Data Gateway (ePDG) שאיתם צריך להתחבר.
במקרה של רשת שאינה בטוחה נפתח ערוץ ipsec :
לקוח הקצה יפתח ערוץ IPSEC/IKEv2 (
5996 ו 3GPP TS 33.402) לשרת בשביל שנוכל להשתמש במשאבי הרשת. ההזדהות (NAI) תהיה במבנה של IMSI@Realm (או מזהה מכשיר תחת realm) וזה ימולא תחת ה IDi בשדה ה IDr נמלא את ה APN שצריך להתחבר בתוך ה ePDG .
לאחר שיבוצע אימות כלפי ה ePDG ונקבל אישור לפתיחת session לאחר מכן לקוח ה
SIP-IMS שלנו יבצע invite לקבל שירות.
לצערי הרב על התהליך יש
פטנט מה שבתאוריה יכול לפגוע בשימוש בזה בפתרונות קוד פתוח.
במקרה של רשת מאובטחת לא מקימים תעלה, האימות מתבצע קרוב ל חיבור ל AP ע"י אחד מאפשרויות האימות מבוססי ה EAP, לבסוף לקוח הסיפ יבצע register בשביל להתחיל להשתמש במשאבי הרשת.
הכתובת config.rcs.pub.3gppnetwork.org מאפשר ממשק HTTP לקבל את מאפייני החיבור (זה rcs רגיל) ,
xcap הוא אותו ה
xcap שאנו משתמשים ברכיבי ה SIP כאשר אנו מדברים עם רשתות LTE ו 3G. לצערי הרב ktp ו linphone לא מציגים דרך קלה לעבוד עם xcap.
בצד הלקוח -
בשביל שנוכל להשתמש באפשרויות האלה אנו נצטרך לקוח wpa_suppliant עדכני , לקוח SIP ולקוח ipsec איתו נוכל להתחבר לרשת רכיב חומרה שיודע לקרוא כרטיסי SIM או פשוט מכשיר סלולאר שיודע לתמוך ב WiFi Calling ו LTE.
עבור שירותי IMS אחרים נצטרך להפעיל אפליקציות בהתאם לשירות אבל מכשיר הסלולאר שלנו עושה זאת עבורנו.
אני מאמין ש linphone ידע להתמודד טוב עם SIP-IMS ב VoWiFi עם המגבלות הבאות :
אני חושב שהתמיכה ב SMS over IP תהיה לוקה בחסר (יש תמיכה ב
3428 ונראה לי גם ב
4976 אבל לא בטוח שיש תמיכה בכל מה שתחת
TS.2431) , הודעות חירום לא יעבדו (כי זה לא מוגדר) אבל פעולות של USSD ככל הנראה כי יעבדו.
מפתחי אפליקציות קצה יכולים לראות את דרישות ה IMS בRFC ולממש את IR.92 (מה שיאפשר לעבוד גם ב VoLTE וגם ב VoWifi).
בגלל קיום שלושת הגישות להודעות מיידיות ככל הנראה יהיו בעיות אבל אני מאוד מקווה שהכל יממוש.
אצל חלק מהספקי שירותי ה SIP משתמשים בצורה הקומפקטית של כותרות הסיפ מה שגורם לאיבד חלק מהמידע ומקשה על הפיענוח, אם אנחנו עובדים כבר בVoWiFi הייתי מאוד שמח אם מפתחי אפליקציות לא היו עושים זאת ומשתמשים בשדה המלא.
רכיב התקשורת (UE) שלנו יחפש קודם כל רשתות שהוא מכיר (ויודע שניתן להתחבר אליהם אם הם trusted), יבצע זאת ע"י מעבר שמות או יחפש רשתות שמאשרות ביצוע הזדהות סים (EAP-AKA/SIM וכו'). אם זה לא עבר יעבור למוד ה untrstursted בו יחפש את הנקודה אליה צריך להתחבר (לפי רשת הסלולאר שלנו כמו t-mobile.com או לפי הכתובות הרשומות תחת 3gppnetwork).
האימות נכון להיום (שמאפשר את שימוש) כולל דברים מבוססי סים (EAP-AKA) אבל גם דברים שאינם דורשים סים (מה שמאפשר לטאבלט ולדביאן שלנו להתחבר לרשת האלחוט באמצעי EAP-TTLS ו EAP-TLS).
במידה וה AP שלנו דורש הזדהות (hybrid mode או Trusted Mode) את חותמות הלקוח שקיבלנו יש לשמור תחת
etc/ssl/certs/ ולהתאים את wpa_supplicant והדפדנים לקרוא משם דוגמאות (כמובן לשנות את הערכים לפי מה שקיבלתם מהספק).
network={
ssid="TRUSTED-GSM-SSID"
scan_ssid=1
key_mgmt=WPA-EAP
pairwise=CCMP TKIP
group=CCMP TKIP
eap=TLS
identity="$(nonuiccid)@blablagsm.tld"
ca_cert="/etc/certs/cacert.pem"
client_cert="/etc/certs/client_blablagsm.pem"
#or
#private_key="client_blablagsm.pem"
#private_key_passwd="secretuserpassword"
}
או במקרה של TTLS :
network={
ssid="UNTRUSTED-GSM-SSID"
key_mgmt=WPA-EAP
eap=TTLS
scan_ssid=1
pairwise=CCMP TKIP
group=CCMP TKIP
anonymous_identity="anon@blablagsm.tld"
identity="$(nonuiccid)@blablagsm.tld"
ca_cert="/etc/certs/ca.pem"
phase2="autheap=TLS"
ca_cert2="/etc/certs/cacert.pem"
client_cert2="/etc/certs/client_blablagsm.pem"
private_key2="key_client_blablagsm.pem"
private_key2_passwd="secretuserpassword"
}
בדביאן על מנת לאפשר את האימות מחדש נצטרך להפעיל ע"י בנייה מחדש עם דגלי ה internetworking מופעלים.
לצערי הרב לא ראיתי פתרון IMS לדסקטופ שתומך בכל הדרישות מה שאומר שנצטרך להפעיל מספר שירותים ו"לנחש" מה חסר בשביל סיפוק השירות.
אבל אני מאמין שלאחר שהשירות כבר קיים בארבעת הספקים הגדולים בארה"ב ואורנג' העולמית משהוא כבר יתאים את אפליקציות ה GUI הקיימות היום.
בצד השרת -
בצד הePDG נוכל להשתמש במחשבי דביאן רגילים, שמריץ שירותים סטאנדרטיים כמו שרת דיאמטר, שירות DNS, שרת ipsec, שרת xcap, שרת איכון גאוגרפי, שירותי SIP ומחבר לשירותי ה IMS של הרשת או משתמש ב OpenIMSCore (או דומה לו) בשביל לספק את היכולות הנדרשות.
הרשתות שבוחרות בשיטת ה untrusted כמובן חשופות להתקופות רגילות (דוגמה
T-Mobile) אבל ההוזלה והיכולת להשתמש בצד שלישי בקלות בשביל לספק שירות פותחת אפשרויות שעולות על הסכנה בהתקפות.
