מהרגע שהמכשיר הנו במצב המחובר, ה- LMP
יכול להתחיל ביצירת הקשר. ה- LMP
משתמש בחבילות ה-LMP
הקבועות שלו לשם כך, אשר נשלחות על ידי פס בסיס ב- payload
שלו, במקום חבילות L2CAP
בעלות עדיפות גבוהה יותר. חבילת ה- LMP
כוללת opcode,
תעודות זיהוי של טרנזאקציות ותכולה מסוימת (תלוי ב- opcode).
ניתן לזהות חבילות LMP
אותן מקבל המכשיר משדה L_CH
בכותרת של חבילת פס הבסיס. אז נשלחות חבילות אלו ל- LMP
ולא ל- L2CAP
או לשכבות גבוהות יותר. ניתן לסכם את הצעדים הבסיסיים ביצירת
הקשר:
1.נעשה
שימוש בחבילות
כדי להעביר מידע אודות קונפיגורציה ללא אינטראקציה של ה- host.
2.
חבילת ה-
LMP_host_connect_request
נשלחת.
3.
המכשיר הרחוק מגיב עם LMP_not_accepted,
אם היישום אותו ביקש המכשיר הראשון לא רוצה או לא יכול להגיב.
במקרה והיישום יכול/רוצה להגיב, נשלחת LMP_accepted
כתגובה.
4.
העבד
המגיב יכול לבקש החלפת תפקידים, אם יש צורך בכך מסיבה כלשהי.
המכשיר הראשון מגיב עם החבילה המתאימה לקבלה או דחייה של הבקשה.
כעת הקשר קיים ברמה של מנהל הקשר (Link
Manager).
יתכן והיישום לא יידע אילו שירותים קיימים בעבד לו קרא ולכן ישתמש
ב- SDP
לגלות זאת.
SDP
סביבת ה-
Bluetooth
משתנה במהירות ולכן יש לגלות את השירותים הקיימים תוך כדי לקיחת
נקודה זו בחשבון. ה- SDP
מספק אמצעים עבור היישום לגלות מהם השירותים הקיימים והמאפיינים
שלהם, כפי שמתואר בספציפיקציות היסוד.
מכשיר Bluetooth
אשר מעוניין לחשוף את שירותיו מריץ שרת SDP.
מכשיר המעוניין לגלות שירותים במכשירים אחרים מריץ לקוח SDP.
ניתן להריץ לקוח אחד עבור כל יישום אבל מכשיר אחד מריץ רק שרת
SDP
אחד. שרת ה- SDP
מקיים רישום של כל שירות אותו מאפשר המכשיר לחפש. לקוח שולח בקשה
לשרת. הבקשה עשויה להיות חיפוש אחר קבוצה מסוימת של שירותים או
ניסיון חיפוש על מנת לראות את כל קבוצות השירותים המוצעות. השרת
מגיב עם התגובה המתאימה. אם למכשיר השרת היו רק מספר שירותים, לא
ניתן לחלקם לקבוצות וידיות השירות שלהן נשלחות ל- slave.
אם לא כך הדבר, נשלחים תיאורי קבוצות והלקוח יכול לחפש אחר פרטים
נוספים בתוך הקבוצה. ה- SDP
מאפשר רק לחפש שירותים. הגישה צריכה להיעשות דרך פרוטוקולים אחרים,
המבוססים על
L2CAP.
