Makalede "", NB-IoT ağının paket çekirdeğinin mimarisinden bahsederken, yeni bir SCEF düğümünün görünümünden bahsetmiştik. Üçüncü bölümde ne olduğunu ve neden gerekli olduğunu açıklıyoruz.
Bir M2M hizmeti oluştururken uygulama geliştiricileri aşağıdaki sorularla karşı karşıya kalır:
- cihazların nasıl tanımlanacağı;
- hangi doğrulama ve kimlik doğrulama algoritmasının kullanılacağı;
- cihazlarla etkileşim için hangi aktarım protokolünün seçileceği;
- Verilerin cihazlara güvenilir bir şekilde nasıl iletileceği;
- onlarla veri alışverişine ilişkin kuralların nasıl organize edileceği ve oluşturulacağı;
- durumlarının çevrimiçi olarak nasıl izlenebileceği ve hakkında bilgi alınabileceği;
- verileri bir grup cihazınıza aynı anda nasıl ileteceğiniz;
- verilerin bir cihazdan birden fazla istemciye aynı anda nasıl gönderileceği;
- Cihazınızı yönetmek için ek operatör hizmetlerine nasıl birleşik erişim elde edebileceğiniz.
Bunları çözmek için, teknik açıdan tescilli "ağır" çözümler yaratmak gerekir; bu da işçilik maliyetlerinin ve pazara sunma süresinin artmasına neden olur. Yeni SCEF düğümünün kurtarmaya geldiği yer burasıdır.
3GPP tarafından tanımlandığı gibi, SCEF (hizmet yeteneği açığa çıkarma işlevi), işlevi API'ler aracılığıyla 3GPP ağ arayüzleri tarafından sağlanan hizmetleri ve yetenekleri güvenli bir şekilde ortaya çıkarmak olan 3GPP mimarisinin tamamen yeni bir bileşenidir.
Basit bir ifadeyle SCEF, ağ ile uygulama sunucusu (AS) arasında bir aracıdır; sezgisel, standartlaştırılmış bir API arayüzü aracılığıyla NB-IoT ağındaki M2M cihazınızı yönetmek için operatör hizmetlerine tek bir pencereden erişim sağlar.
SCEF, bir operatörün ağının karmaşıklığını gizleyerek uygulama geliştiricilerin cihazlarla etkileşime yönelik karmaşık, cihaza özgü mekanizmaları soyutlamasına olanak tanır.
SCEF API, ağ protokollerini uygulama geliştiricileri için tanıdık bir API'ye dönüştürerek yeni hizmetlerin oluşturulmasını kolaylaştırır ve pazara sunma süresini kısaltır. Yeni düğüm aynı zamanda mobil cihazların tanımlanması/doğrulanması, cihaz ile AS arasındaki veri alışverişine ilişkin kuralların tanımlanması, uygulama geliştiricilerin bu işlevleri kendi taraflarında uygulaması ihtiyacını ortadan kaldırma ve bu işlevleri operatörün omuzlarına kaydırma işlevleri de içeriyor.
SCEF, uygulama sunucularının kimlik doğrulaması ve yetkilendirilmesi, UE mobilitesinin sürdürülmesi, veri aktarımı ve cihaz tetikleme, ek hizmetlere erişim ve operatör ağ yetenekleri için gerekli arayüzleri kapsar.
AS'ye doğru tek bir T8 arayüzü, 3GPP tarafından standartlaştırılmış bir API (HTTP/JSON) vardır. T8 dışındaki tüm arayüzler DIAMETER protokolüne göre çalışır (Şekil 1).
T6a – SCEF ve MME arasındaki arayüz. Mobilite/Oturum yönetimi prosedürleri, IP dışı verilerin iletimi, olayların izlenmesinin sağlanması ve bunlarla ilgili raporların alınması için kullanılır.
S6t – SCEF ve HSS arasındaki arayüz. Abone kimlik doğrulaması, uygulama sunucularının yetkilendirilmesi, harici kimlik ve IMSI/MSISDN kombinasyonunun elde edilmesi, izleme olaylarının sağlanması ve bunlarla ilgili raporların alınması için gereklidir.
S6m/T4 – SCEF'den HSS'ye ve SMS-C'ye arayüzler (3GPP, NB-IoT ağlarında cihaz tetikleme ve SMS iletimi için kullanılan MTC-IWF düğümünü tanımlar. Ancak tüm uygulamalarda bu düğümün işlevselliği, SCEF, devreyi basitleştirmek için ayrı olarak ele almayacağız). SMS göndermek ve SMS merkeziyle etkileşime geçmek için yönlendirme bilgilerini almak için kullanılır.
T8 – Uygulama sunucularıyla SCEF etkileşimi için API arayüzü. Hem kontrol komutları hem de trafik bu arayüz üzerinden iletilir.
*gerçekte daha fazla arayüz vardır; burada yalnızca en temel olanlar listelenmiştir. Tam liste 3GPP 23.682'de (4.3.2 Referans Noktaları Listesi) verilmiştir.
SCEF'in temel işlevleri ve hizmetleri aşağıdadır:
- SIM kart tanımlayıcısının (IMSI) harici kimliğe bağlanması;
- IP dışı trafiğin iletimi (IP Dışı Veri Teslimatı, NIDD);
- harici grup kimliğini kullanan grup işlemleri;
- onay ile veri iletim modu desteği;
- MO (Mobil Kaynaklı) ve MT (Mobil Sonlandırılmış) verilerinin ara belleğe alınması;
- cihazların ve uygulama sunucularının kimlik doğrulaması ve yetkilendirilmesi;
- bir UE'den gelen verilerin birkaç AS tarafından eşzamanlı kullanımı;
- özel UE durum izleme işlevleri için destek (MONTE – Olayları İzleme);
- cihaz tetikleme;
- IP olmayan veri dolaşımının sağlanması.
AS ve SCEF arasındaki etkileşimin temel prensibi sözde şemaya dayanmaktadır. abonelikler. Belirli bir UE için herhangi bir SCEF hizmetine erişim kazanmak gerekiyorsa, uygulama sunucusunun, talep edilen hizmetin belirli API'sine bir komut göndererek bir abonelik oluşturması ve yanıt olarak benzersiz bir tanımlayıcı alması gerekir. Bundan sonra bu hizmet çerçevesinde UE ile yapılan tüm diğer eylemler ve iletişimler bu tanımlayıcı kullanılarak gerçekleştirilecektir.
Harici Kimlik: Evrensel cihaz tanımlayıcı
SCEF üzerinden çalışırken AS ile cihazlar arasındaki etkileşim şemasındaki en önemli değişikliklerden biri evrensel bir tanımlayıcının ortaya çıkmasıdır. Artık klasik 2G/3G/LTE ağında olduğu gibi telefon numarası (MSISDN) veya IP adresi yerine uygulama sunucusunun cihaz tanımlayıcısı “harici kimlik” haline geliyor. Standart tarafından uygulama geliştiricilerin aşina olduğu bir formatta tanımlanmıştır " @ "
Geliştiricilerin artık cihaz kimlik doğrulama algoritmaları uygulamasına gerek yok; ağ bu işlevi tamamen üstleniyor. Harici Kimlik IMSI'ye bağlıdır ve geliştirici, belirli bir harici kimliğe erişirken bunun belirli bir SIM kartla etkileşime girdiğinden emin olabilir. Bir SIM çipi kullanırken, harici kimliğin belirli bir cihazı benzersiz bir şekilde tanımladığı tamamen benzersiz bir durumla karşılaşırsınız!
Ayrıca, birkaç harici kimlik bir IMSI'ye bağlanabilir; harici kimlik, belirli bir cihazdaki belirli bir hizmetten sorumlu belirli bir uygulamayı benzersiz şekilde tanımladığında daha da ilginç bir durum ortaya çıkar.
Bir grup tanımlayıcı da görünür - bir dizi bireysel harici kimlik içeren harici grup kimliği. Artık AS, SCEF'e yapılan tek bir taleple grup işlemlerini başlatabiliyor; tek bir mantıksal grupta birleştirilmiş birden fazla cihaza veri veya kontrol komutları gönderebiliyor.
AS geliştiricileri için yeni bir cihaz tanımlayıcısına geçişin anında olamayacağı gerçeği nedeniyle SCEF, standart bir numara olan MSISDN aracılığıyla UE ile AS iletişimi olasılığını bıraktı.
IP dışı trafiğin iletimi (IP Dışı Veri Dağıtımı, NIDD)
NB-IoT'de, küçük miktarlarda veri aktarımına yönelik mekanizmaların optimizasyonunun bir parçası olarak, IPv4, IPv6 ve IPv4v6 gibi halihazırda mevcut PDN türlerine ek olarak, IP olmayan başka bir tür ortaya çıktı. Bu durumda cihaza (UE) bir IP adresi atanmaz ve veriler IP protokolü kullanılmadan iletilir. Bu tür bağlantılara yönelik trafik iki şekilde yönlendirilebilir: klasik - MME -> SGW -> PGW ve ardından PtP tüneli üzerinden AS'ye (Şekil 2) veya SCEF kullanılarak (Şekil 3).
Klasik yöntem, IP başlıklarının bulunmamasından dolayı iletilen paketlerin boyutunun azaltılması dışında, IP trafiğine göre herhangi bir özel avantaj sunmamaktadır. SCEF kullanımı bir dizi yeni olasılığın önünü açar ve cihazlarla etkileşim prosedürlerini önemli ölçüde basitleştirir.
SCEF aracılığıyla veri aktarırken klasik IP trafiğine göre çok önemli iki avantaj ortaya çıkar:
MT trafiğinin harici kimlik aracılığıyla cihaza iletilmesi
Klasik bir IP cihazına mesaj göndermek için AS'nin IP adresini bilmesi gerekir. Burada bir sorun ortaya çıkıyor: Cihaz genellikle kayıt sırasında "gri" bir IP adresi aldığından, internette bulunan uygulama sunucusuyla gri adresin beyaza çevrildiği bir NAT düğümü aracılığıyla iletişim kurar. Gri ve beyaz IP adreslerinin kombinasyonu, NAT ayarlarına bağlı olarak sınırlı bir süre devam eder. Ortalama olarak, TCP veya UDP için - beş dakikadan fazla değil. Yani bu cihazla 5 dakika içerisinde veri alışverişi olmazsa bağlantı kopacak ve AS ile oturumun başlatıldığı beyaz adresten cihaza artık erişilmeyecektir. Birkaç çözüm var:
1. Kalp atışını kullanın. Bağlantı kurulduktan sonra cihazın AS ile birkaç dakikada bir paket alışverişi yapması gerekir, böylece NAT çevirilerinin kapanması önlenir. Ancak burada herhangi bir enerji verimliliğinden söz edilemez.
2. Gerekirse her seferinde AS'deki cihaz için paketlerin mevcut olup olmadığını kontrol edin - uplink'e bir mesaj gönderin.
3. Uygulama sunucusunun ve cihazların aynı alt ağda olacağı özel bir APN (VRF) oluşturun ve cihazlara statik IP adresleri atayın. İşe yarayacaktır ama binlerce, onbinlerce cihazdan oluşan bir filodan bahsederken bu neredeyse imkansızdır.
4. Son olarak en uygun seçenek: IPv6 kullanın; IPv6 adreslerine İnternet'ten doğrudan erişilebildiğinden NAT gerektirmez. Ancak bu durumda bile cihaz yeniden kaydedildiğinde yeni bir IPv6 adresi alacak ve artık önceki adres kullanılarak erişilemeyecektir.
Buna göre, cihazın yeni IP adresini bildirmek için sunucuya cihaz tanımlayıcı içeren bir miktar başlatma paketi göndermek gerekir. Daha sonra AS'den gelecek onay paketini bekleyin, bu da enerji verimliliğini etkiler.
Bu yöntemler, cihazın katı özerklik gereksinimlerine sahip olmadığı ve sonuç olarak yayın süresi ve trafik konusunda herhangi bir kısıtlamanın olmadığı 2G/3G/LTE cihazlarda iyi çalışır. Bu yöntemler yüksek enerji tüketimi nedeniyle NB-IoT için uygun değildir.
SCEF bu sorunu çözer: AS'nin tek cihaz tanımlayıcısı harici bir kimlik olduğundan, AS'nin yalnızca belirli bir harici kimlik için SCEF'e bir veri paketi göndermesi gerekir ve gerisini SCEF halleder. Cihazın PSM veya eDRX güç tasarrufu modunda olması durumunda, veriler arabelleğe alınacak ve cihaz kullanılabilir olduğunda teslim edilecektir. Cihazın trafiğe uygun olması durumunda veriler anında iletilecektir. Aynı durum yönetim ekipleri için de geçerlidir.
AS herhangi bir zamanda ara belleğe alınmış mesajı UE'ye geri çağırabilir veya yeni bir mesajla değiştirebilir.
Tamponlama mekanizması, MO verilerini UE'den AS'ye aktarırken de kullanılabilir. SCEF, verileri AS'ye hemen teslim edemiyorsa, örneğin AS sunucularında bakım çalışmaları devam ediyorsa, bu paketler arabelleğe alınacak ve AS kullanılabilir hale gelir gelmez teslim edilmesi garanti edilecektir.
Yukarıda belirtildiği gibi, bir AS için belirli bir hizmete ve UE'ye erişim (ve NIDD bir hizmettir), SCEF tarafındaki kurallar ve politikalar tarafından düzenlenir; bu, bir UE'den gelen verilerin birkaç AS tarafından eşzamanlı olarak kullanılmasına ilişkin benzersiz olasılığa izin verir. Onlar. eğer birkaç AS bir UE'ye abone olmuşsa, UE'den veri aldıktan sonra SCEF bunu abone olan tüm AS'lere gönderecektir. Bu, özel cihazlardan oluşan bir filonun yaratıcısının verileri birkaç müşteri arasında paylaştığı durumlar için çok uygundur. Örneğin, NB-IoT üzerinde çalışan bir hava durumu istasyonları ağı oluşturarak, onlardan gelen verileri aynı anda birçok hizmete satabilirsiniz.
Garantili mesaj teslim mekanizması
Güvenilir Veri Hizmeti, örneğin TCP'de el sıkışma gibi protokol düzeyinde özel algoritmalar kullanılmadan MO ve MT mesajlarının garantili teslimini sağlayan bir mekanizmadır. UE ile SCEF arasında değiş tokuş yapıldığında mesajın hizmet kısmına özel bir bayrak dahil edilerek çalışır. Trafiği iletirken bu mekanizmanın etkinleştirilip etkinleştirilmeyeceğine AS tarafından karar verilir.
Mekanizma etkinleştirilirse UE, MO trafiğinin garantili teslimatını gerektirdiğinde paketin üst kısmında özel bir işaret içerir. Böyle bir paketin alınması üzerine SCEF, UE'ye bir alındı bildirimiyle yanıt verir. UE onay paketini almazsa SCEF'e giden paket yeniden gönderilecektir. Aynı şey MT trafiği için de geçerli.
Cihaz izleme (olayların izlenmesi - MONTE)
Yukarıda bahsedildiği gibi, SCEF işlevselliği, diğer şeylerin yanı sıra, sözde UE'nin durumunu izlemeye yönelik işlevleri içerir. cihaz izleme. Ve eğer yeni tanımlayıcılar ve veri aktarım mekanizmaları mevcut prosedürlerin (çok ciddi de olsa) optimizasyonlarıysa, o zaman MONTE, 2G/3G/LTE ağlarında bulunmayan tamamen yeni bir işlevselliktir. MONTE, AS'nin bağlantı durumu, iletişim kullanılabilirliği, konum, dolaşım durumu vb. gibi cihaz parametrelerini izlemesine olanak tanır. Biraz sonra her biri hakkında daha ayrıntılı olarak konuşacağız.
Bir cihaz veya cihaz grubu için herhangi bir izleme olayının etkinleştirilmesi gerekiyorsa AS, harici kimlik veya harici grup kimliği, AS tanımlayıcısı, izleme gibi parametreleri içeren ilgili API MONTE komutunu SCEF'ye göndererek ilgili hizmete abone olur. AS'nin almak istediği raporların türü, sayısı. AS'nin isteği yürütme yetkisi varsa SCEF, türüne bağlı olarak olayı HSS veya MME'ye sağlayacaktır (Şekil 4). Bir olay meydana geldiğinde MME veya HSS, SCEF'e bir rapor oluşturur ve SCEF bunu AS'ye gönderir.
“Bir coğrafi bölgede bulunan UE sayısı” haricindeki tüm etkinliklerin provizyonu HSS aracılığıyla gerçekleşir. "IMSI-IMEI İlişkilendirmesinin Değişikliği" ve "Dolaşım Durumu" olmak üzere iki olay doğrudan HSS'de takip edilir, geri kalanı MME'de HSS tarafından sağlanacaktır.
Etkinlikler tek seferlik veya periyodik olabilir ve türlerine göre belirlenir.
Bir olayla ilgili raporun gönderilmesi (raporlama), olayı doğrudan SCEF'e izleyen düğüm tarafından gerçekleştirilir (Şekil 5).
Önemli nokta: İzleme olayları, hem SCEF aracılığıyla bağlanan IP olmayan cihazlara hem de MME-SGW-PGW aracılığıyla klasik şekilde veri aktaran IP cihazlarına uygulanabilir.
İzleme olaylarının her birine daha yakından bakalım:
Bağlantı kaybı - AS'ye UE'nin artık veri trafiği veya sinyalizasyon için uygun olmadığını bildirir. Olay, UE için "mobil erişilebilirlik zamanlayıcısının" MME'de süresi dolduğunda meydana gelir. Bu tür bir izleme talebinde AS, "Maksimum Tespit Süresi" değerini gösterebilir - eğer bu süre zarfında UE herhangi bir aktivite göstermezse, AS'ye, nedeni belirtilerek UE'nin kullanılamadığı konusunda bilgi verilecektir. Bu olay ayrıca UE'nin ağ tarafından herhangi bir nedenden dolayı zorla çıkarılması durumunda da meydana gelir.
* Ağın, cihazın hala kullanılabilir durumda olduğunu bilmesini sağlamak için, periyodik olarak bir güncelleme prosedürü başlatır - İzleme Alanı Güncellemesi (TAU). Bu prosedürün sıklığı, değeri Ekleme prosedürü veya bir sonraki TAU sırasında cihaza iletilen T3412 veya (PSM durumunda T3412_extished) zamanlayıcı kullanılarak ağ tarafından ayarlanır. Mobil erişilebilirlik zamanlayıcısı genellikle T3412'den birkaç dakika daha uzundur. UE, "Mobil erişilebilirlik zamanlayıcısının" sona ermesinden önce bir TAU yapmamışsa ağ, bunun artık erişilebilir olmadığını kabul eder.
UE erişilebilirliği – UE'nin DL trafiği veya SMS için ne zaman kullanılabilir hale geldiğini belirtir. Bu, UE çağrı için uygun hale geldiğinde (eDRX modunda bir UE için) veya UE ECM-CONNECTED moduna girdiğinde (PSM veya eDRX modunda bir UE için) meydana gelir; TAU yapar veya bir uplink paketi gönderir.
Konum raporlama – Bu tür izleme olayları AS'nin UE'nin konumunu sorgulamasına olanak tanır. PSM veya eDRX güç tasarrufundaki cihazlar için geçerli olan mevcut konum (Geçerli Konum) veya bilinen son konum (cihazın en son TAU yaptığı veya trafiği aktardığı hücre kimliğine göre belirlenen Bilinen Son Konum) talep edilebilir. modlar. "Mevcut Konum" için AS tekrarlanan yanıtlar talep edebilir ve MME, cihazın konumu her değiştiğinde AS'yi bilgilendirir.
IMSI-IMEI İlişkilendirmesinin Değişikliği – Bu olay etkinleştirildiğinde SCEF, IMSI (SIM kart tanımlayıcı) ve IMEI (cihaz tanımlayıcı) kombinasyonundaki değişiklikleri izlemeye başlar. Bir olay meydana geldiğinde AS'yi bilgilendirir. Planlanmış değiştirme çalışmaları sırasında harici bir kimliği cihaza otomatik olarak yeniden bağlamak için kullanılabilir veya cihazın çalınması durumunda tanımlayıcı olarak kullanılabilir.
Dolaşım Durumu - bu tür izleme AS tarafından UE'nin ev ağında mı yoksa dolaşım ortağının ağında mı olduğunu belirlemek için kullanılır. İsteğe bağlı olarak cihazın kayıtlı olduğu operatörün PLMN'si (Kamu Kara Mobil Şebekesi) iletilebilir.
İletişim hatası — Bu tür izleme, radyo erişim ağından (S1-AP protokolü) alınan bağlantı kaybının nedenlerine (serbest bırakma neden kodu) bağlı olarak AS'yi cihazla iletişimdeki hatalar hakkında bilgilendirir. Bu olay, örneğin eNodeb'in aşırı yüklenmesi (Radyo kaynakları mevcut değil) veya cihazın kendisindeki bir arıza nedeniyle (UE Kayıplı Radyo Bağlantısı) ağdaki sorunlar nedeniyle iletişimin neden başarısız olduğunu belirlemeye yardımcı olabilir.
DDN Arızasından Sonra Kullanılabilirlik – bu olay AS'ye, bir iletişim arızasından sonra cihazın kullanılabilir hale geldiğini bildirir. Bir cihaza veri aktarmaya ihtiyaç duyulduğunda kullanılabilir, ancak UE ağdan gelen bir bildirime (çağrı) yanıt vermediğinden ve veriler teslim edilmediğinden önceki girişim başarılı olmadı. UE için bu tür bir izleme talep edilmişse, cihaz gelen bir iletişim kurduğunda, bir TAU yaptığında veya yukarı bağlantıya veri gönderdiğinde AS, cihazın kullanılabilir hale geldiği konusunda bilgilendirilecektir. DDN (aşağı bağlantı veri bildirimi) prosedürü MME ve S/P-GW arasında çalıştığından, bu tür izleme yalnızca IP cihazları için mümkündür.
PDN Bağlantı Durumu – cihaz durumu değiştiğinde (PDN bağlantı durumu) - bağlantı (PDN aktivasyonu) veya bağlantı kesildiğinde (PDN silinmesi) AS'yi bilgilendirir. Bu, AS tarafından UE ile iletişimi başlatmak için veya tam tersi şekilde iletişimin artık mümkün olmadığını anlamak için kullanılabilir. Bu tür izleme, IP ve IP olmayan cihazlar için kullanılabilir.
Bir coğrafi bölgede bulunan UE'lerin sayısı – Bu tür izleme, AS tarafından belirli bir coğrafi alandaki UE'lerin sayısını belirlemek için kullanılır.
Cihaz tetikleme)
2G/3G ağlarında, ağdaki kayıt prosedürü iki aşamalıydı: ilk olarak cihaz SGSN'ye kaydoldu (ekleme prosedürü), ardından gerekirse paket ağ geçidi (GGSN) ile bağlantı olan PDP içeriğini etkinleştirdi. Verileri iletmek için. 3G ağlarında bu iki prosedür sırayla gerçekleşti; cihaz veri aktarması gereken anı beklemedi, ancak ekleme işlemi tamamlandıktan hemen sonra PDP'yi etkinleştirdi. LTE'de bu iki prosedür tek bir prosedürde birleştirildi; yani, cihaz bağlanırken hemen eNodeB aracılığıyla MME-SGW-PGW'ye PDN bağlantısının (2G/3G'deki PDP'ye benzer) etkinleştirilmesini talep etti.
NB-IoT, bağlantı yöntemini “PDN olmadan ekle” olarak tanımlar, yani UE, PDN bağlantısı kurmadan bağlanır. Bu durumda trafik iletilemez, yalnızca SMS alabilir veya gönderebilir. Böyle bir cihaza PDN'yi etkinleştirmek ve AS'ye bağlanmak üzere komut göndermek için “Cihaz tetikleme” işlevi geliştirildi.
AS'den böyle bir UE'yi bağlamak için bir komut alındığında SCEF, SMS merkezi aracılığıyla cihaza bir kontrol SMS'i göndermeyi başlatır. Cihaz, bir SMS alırken PDN'yi etkinleştirir ve daha fazla talimat almak veya veri aktarmak için AS'ye bağlanır.
Cihaz aboneliğinizin SCEF'te sona erdiği zamanlar olabilir. Evet, aboneliğin operatör tarafından belirlenen veya AS ile mutabakata varılan kendi ömrü vardır. Süre dolduğunda PDN, MME'de devre dışı bırakılacak ve cihaz AS tarafından kullanılamaz hale gelecektir. Bu durumda “Cihaz tetikleme” işlevi de yardımcı olacaktır. AS'den yeni veri alındığında SCEF, cihazın bağlantı durumunu öğrenecek ve verileri SMS kanalı aracılığıyla iletecektir.
Sonuç
SCEF'in işlevselliği elbette yukarıda açıklanan hizmetlerle sınırlı değildir ve sürekli olarak gelişip genişlemektedir. Şu anda bir düzineden fazla hizmet SCEF için standartlaştırılmıştır. Şimdi sadece geliştiricilerin talep ettiği ana işlevlere değindik; geri kalanından gelecek makalelerde bahsedeceğiz.
Hemen akla şu soru geliyor: Olası vakaların ön testi ve hata ayıklaması için bu "mucize" düğüme test erişimi nasıl elde edilir? Hepsi çok basit. Herhangi bir geliştirici, bağlantının amacını, olası durumun açıklamasını ve iletişim için iletişim bilgilerini belirtmenin yeterli olduğu iot.info@mts.ru adresine bir istek gönderebilir.
Gelecek sefere kadar!
Yazarlar:
- Yakınsak çözümler ve multimedya hizmetleri bölümünün kıdemli uzmanı Sergey Novikov ,
- yakınsak çözümler ve multimedya hizmetleri departmanı uzmanı Alexey Lapshin
Kaynak: habr.com
