رؤى الصناعة
2026-09-15 16:15:35

إجراء تحديث التسجيل الدوري في شبكة 5GC الأساسية

يتيح تحديث التسجيل الدوري في 5GC لجهاز UE المسجل تحديث حالة إمكانية الوصول والتنقل بشكل دوري. يشرح سلوك T3512، والتشغيل في CM-IDLE، ورسالة Registration Request، والمعالجة المبسطة في AMF، واستكشاف مشكلات انتهاء المهلة.

بيك تيلكوم

إجراء تحديث التسجيل الدوري في شبكة 5GC الأساسية

عند الساعة 3:00 صباحًا، ترسل بوابة صناعية تعمل بتقنية 5G رسالة Registration Request إلى AMF. لم يتغير TAI منذ التسجيل السابق، و5G-GUTI هو نفسه، ولم يتغير AMF المُقدِّم للخدمة، وربما لم يرسل الجهاز أي بيانات صاعدة منذ عدة ساعات. من منظور إدارة التنقل فقط، لا يحمل الطلب أي معلومات موقع جديدة وقد يبدو وكأنه تسجيل مكرر. لكن حقل نوع التسجيل يحدد بوضوح أنه تحديث تسجيل دوري. ما يحتاج AMF إلى تأكيده ليس المكان الذي انتقل إليه UE، بل أمرًا أكثر أساسية: هل ما زال UE حاضرًا، وهل ينبغي اعتباره قابلًا للوصول عبر النداء، وهل يجب الاستمرار في الاحتفاظ بسياق تسجيله؟

في إدارة التسجيل ضمن 5GC، يعالج تحديث التسجيل بسبب التنقل وتحديث التسجيل الدوري مشكلتين مختلفتين. الأول يُشغَّل بسبب التنقل ويركز على تحديث الموقع والتوجيه، بينما يُشغَّل الثاني عند انتهاء T3512 ويركز على التأكيد الدوري لحالة التسجيل وإمكانية الوصول إلى UE. قد يحتاج UE الذي يبقى في CM-IDLE مدة طويلة إلى الاتصال بالشبكة عند انتهاء T3512 حتى إذا ظل ضمن منطقة التسجيل نفسها وتحت AMF المُقدِّم للخدمة نفسه ولم يتغير موقعه. من خلال هذا التفاعل، تحدّث الشبكة تصورها لإمكانية الوصول إلى UE، وإذا استمر غيابه يمكنها في النهاية تحرير سياق تسجيل قديم عبر إلغاء التسجيل الضمني. لذلك، مفتاح فهم تحديث التسجيل الدوري ليس ما إذا كانت Registration Request تحمل موقعًا جديدًا، بل كيفية إدارة T3512، وكيف يطلق UE الإجراء في CM-IDLE، وكيف يفسر AMF حقل نوع التسجيل وسياق UE، وكيف تتعامل الشبكة مع UE لم ينفذ التحديث في الوقت المحدد.

لماذا نحتاج إلى تحديث تسجيل دوري إذا لم يتحرك UE؟

بعد إتمام التسجيل الأولي، يدخل UE حالة 5GS Registered. لكن كلمة «مسجل» لا تعني أن UE يحافظ باستمرار على اتصال إشارات NAS مع AMF. تدخل كثير من الهواتف الذكية وأجهزة إنترنت الأشياء والأجهزة الطرفية ذات حركة البيانات المنخفضة إلى CM-IDLE عند غياب نشاط البيانات أو الإشارات، بهدف تقليل استهلاك موارد الراديو والشبكة الأساسية.

من منظور UE، يوفر البقاء غير نشط لفترات طويلة الموارد. أما من منظور 5GC، فينشأ سؤال مهم: آخر مرة عرف فيها AMF أن UE متاح ربما كانت قبل عشرات الدقائق أو حتى ساعات. منذ ذلك الحين قد يكون UE قد أُطفئ، أو فقد التغطية، أو نفدت بطاريته، أو قد يكون ببساطة ما يزال متمركزًا طبيعيًا على الشبكة من دون توليد أي حركة بيانات.

إذا احتفظت الشبكة الأساسية بتسجيل UE إلى أجل غير مسمى، فقد تواصل الاحتفاظ بسياق قديم لجهاز لم يعد قابلًا للوصول. وإذا أزالت السياق بسرعة مفرطة، فقد تضطر جهاز UE ما يزال مسجلًا بصورة طبيعية إلى إنشاء تسجيل جديد من دون حاجة.

يوازن تحديث التسجيل الدوري بين هذين المطلبين. تستخدم الشبكة T3512 لإبلاغ UE بالمدة التي يمكن أن يبقى خلالها من دون تفاعل 5GMM آخر ذي صلة قبل أن يبدأ تحديث تسجيل دوريًا.

لذلك يمكن النظر إلى الإجراء على أنه تحقق دوري من الحالة بين UE و5GC:

       UE مسجل بالفعل
       → يبقى UE في CM-IDLE لفترة ممتدة
       → يستمر T3512 في العد
       → ينتهي T3512
       → يعيد UE إنشاء اتصال إشارات NAS
       → يبدأ UE تحديث التسجيل الدوري
       → يؤكد AMF حالة التسجيل ويحدّثها    

الهدف الأساسي ليس الإبلاغ عن حركة جديدة بين المناطق، بل منع UE والشبكة من البقاء إلى أجل غير مسمى بحالتين غير متزامنتين بشأن ما إذا كان سياق التسجيل الحالي ما يزال صالحًا.

في تحديث التسجيل الدوري ضمن 5GC، يدخل UE إلى CM-IDLE بعد التسجيل ويستمر T3512 في العد، وعند انتهاء المؤقت يعيد UE إنشاء الإشارات ويبدأ تحديث التسجيل الدوري
في تحديث التسجيل الدوري ضمن 5GC، يدخل UE إلى CM-IDLE بعد التسجيل ويستمر T3512 في العد، وعند انتهاء المؤقت يعيد UE إنشاء الإشارات ويبدأ تحديث التسجيل الدوري

متى يبدأ T3512 فعليًا في العد؟

T3512 ليس مجرد مؤقت محلي يختاره UE. تتحكم الشبكة في قيمته، ويمكن لـ AMF إرسال قيمة مؤقت التسجيل الدوري إلى UE ضمن رسالة Registration Accept. ما لم يتلق UE قيمة جديدة لاحقًا، فإنه يستمر في استخدام إعداد T3512 المخزن.

القيمة الافتراضية لـ T3512 وفق 3GPP هي 54 دقيقة، لكن ذلك لا يعني أن كل UE في كل شبكة 5G تجارية يجري تحديثًا كل 54 دقيقة. يستطيع AMF تعيين قيمة مختلفة وفق إعداد الشبكة وسلوك UE ومعلومات الاشتراك والسياسة. إذا عطلت الشبكة T3512 أو ضبطته على صفر، فلن يتم تنفيذ تحديث التسجيل الدوري المقابل.

في سيناريو شائع لوصول 3GPP، إذا لم تستخدم الشبكة قدرة مؤقت التسجيل الدوري الصارم، يبدأ UE أو يعيد تشغيل T3512 عند انتقاله من 5GMM-CONNECTED إلى 5GMM-IDLE. وعندما يعود UE إلى 5GMM-CONNECTED، يتوقف المؤقت عادة. هذا مهم لأن تحديث التسجيل الدوري لا يُنشأ ببساطة وفق ساعة مطلقة بغض النظر عن نشاط UE.

لنفترض أن UE أكمل التسجيل عند 09:00، ثم حرر اتصال إشارات NAS ودخل CM-IDLE مع ضبط T3512 على 54 دقيقة. إذا لم يحدث تفاعل آخر يوقف المؤقت أو يعيد تشغيله أو يغيره، فمن المتوقع أن يدخل UE إجراء تحديث التسجيل الدوري عند انتهاء المؤقت.

يمكن للسلوك المحدد في إصدارات أحدث من المواصفات أن يدعم أيضًا مؤقت تسجيل دوري صارم. في هذا الوضع قد يبدأ T3512 بعد إكمال التسجيل بنجاح، ولا يتوقف لمجرد دخول UE إلى 5GMM-CONNECTED. وإذا انتهى المؤقت بينما UE في الحالة المتصلة، فقد يُعاد تشغيله، بينما يستمر التعامل مع تحديث التسجيل الدوري الفعلي وفق حالة 5GMM الحالية.

لذلك، ظهور «T3512 = 54 دقيقة» في Registration Accept لا يعني تلقائيًا أن Registration Request يجب أن تظهر بعد 54 دقيقة بالضبط. يجب أن يراعي تحليل الإشارات أيضًا ما إذا دخل UE حالة CONNECTED خلال تلك الفترة، وما إذا حدث تسجيل آخر، وما إذا كان الوضع الدوري الصارم مفعّلًا، وما إذا جرى تحديث المؤقت أو تعطيله.

كيف تختلف Registration Request الدورية عن التسجيل الأولي؟

عند انتهاء T3512، يحتاج UE إلى إعادة إنشاء اتصال طبقة التحكم مع الشبكة. وبعد استعادة مسار إشارات NAS عبر gNB، يرسل gNB إلى AMF رسالة NGAP Initial UE Message تحمل معلومات الموقع الحالية لـ UE ورسالة NAS Registration Request.

أهم عنصر معلومات في تحليل الإشارات هو 5GS registration type (نوع تسجيل 5GS) داخل Registration Request. في هذا الإجراء يُضبط على periodic registration updating (تحديث التسجيل الدوري)، ليبلغ AMF بوضوح أن UE لا يلتحق بـ 5GS للمرة الأولى، ولا يحدّث تسجيله لأنه خرج من منطقة التسجيل، بل يجدد تسجيلًا قائمًا بصورة دورية.

يحمل UE عادة أيضًا 5G-GUTI الحالي حتى يتمكن AMF من ربط الطلب بسرعة بسياق UE موجود. وقد تتضمن الرسالة معلومات مثل Last Visited Registered TAI وUE Security Capability وPDU Session Status لمساعدة الشبكة على مطابقة حالة التنقل والجلسات التي يحتفظ بها UE حاليًا.

وبذلك يمكن التمييز منذ بداية مسار الإشارات بين ثلاثة سيناريوهات لـ Registration Request يسهل الخلط بينها:

       التسجيل الأولي: يحتاج UE إلى إنشاء علاقة تسجيل جديدة مع 5GS
       تحديث التسجيل بسبب التنقل: تغير موقع تنقل UE أو شروط منطقة التسجيل
       تحديث التسجيل الدوري: تحتاج علاقة التسجيل الحالية إلى تجديد دوري    

تستخدم الإجراءات الثلاثة Registration Request، لكن أسباب تشغيلها مختلفة جذريًا. عند تحليل إشارات التسجيل في 5GC، لا يكفي رؤية اسم الرسالة «Registration Request» لتحديد الإجراء. أول عنصر يجب فحصه هو نوع تسجيل 5GS.

لماذا يمكن أن يكون التحديث قصيرًا جدًا عندما لا يتغير AMF المُقدِّم للخدمة؟

إحدى أهم خصائص تحديث التسجيل الدوري ليست عدد رسائل الإشارات الجديدة التي يضيفها، بل مدى اختصاره مقارنة بالتسجيل الأولي عندما يظل السياق الحالي صالحًا.

لنفترض أن UE ما يزال ضمن نطاق خدمة AMF نفسه، ولم يحدث تغيير في AMF، وما يزال سياق UE وسياق الأمان المنشآن سابقًا صالحين للاستخدام، ولا يوجد تغيير في الاشتراك أو السياسة يتطلب معالجة إضافية. عندما يستقبل AMF رسالة Registration Request التي تحمل 5G-GUTI الحالي، يمكنه استخدام معلومات GUAMI المرتبطة بهذه الهوية لتحديد أن UE ما يزال مخدومًا محليًا واسترجاع سياق UE المقابل.

في هذه الظروف، لا يلزم بالضرورة تكرار كثير من الإجراءات التي تظهر عادة في التسجيل الأولي الكامل.

إذا كانت الهوية وحالة الأمان ما تزالان صالحتين، فقد لا تكون هناك حاجة إلى إجراء 5G-AKA كامل، ولذلك قد لا يظهر AUSF في مسار الإشارات. وبما أن AMF المُقدِّم للخدمة لم يتغير، فلا يلزم بالضرورة أن يسجل AMF نفسه من جديد لدى UDM أو يسترجع ملف الاشتراك الكامل لمجرد حدوث تحديث دوري. وإذا لم تتغير منطقة الوصول أو السياسة، فقد لا تكون هناك حاجة إلى إجراء PCF AM Policy جديد أيضًا. وإذا لم تكن هناك حاجة لاختيار AUSF أو UDM أو PCF جديد، فقد لا تظهر إجراءات الاكتشاف المقابلة عبر NRF.

لذلك قد يبدو مسار الإشارات المبسط النموذجي كما يلي:

       UE
       → gNB: إعادة إنشاء الوصول
       → AMF: Initial UE Message + Periodic Registration Request
       → AMF: استرجاع سياق UE الحالي باستخدام 5G-GUTI
       → gNB / UE: Registration Accept
       → UE: Registration Complete عند الحاجة    

عبارة «قد لا يكون مطلوبًا» مهمة. يتيح إطار التسجيل في 3GPP للشبكة تنفيذ أي معالجة للهوية أو الأمان أو الاشتراك أو السياسة تكون ضرورية للسياق الحالي. لذلك لا ينبغي تفسير مسار مبسط في شبكة تجارية على أنه تسلسل إلزامي ثابت لكل تحديث تسجيل دوري.

إشارات مبسطة لتحديث التسجيل الدوري في 5GC عندما يبقى AMF المُقدِّم للخدمة من دون تغيير: يرسل UE رسالة Periodic Registration Request عبر gNB، ويسترجع AMF سياق UE الحالي من 5G-GUTI قبل إعادة Registration Accept
إشارات مبسطة لتحديث التسجيل الدوري في 5GC عندما يبقى AMF المُقدِّم للخدمة من دون تغيير: يرسل UE رسالة Periodic Registration Request عبر gNB، ويسترجع AMF سياق UE الحالي من 5G-GUTI قبل إعادة Registration Accept

ما حالات التسجيل التي يمكن لـ Registration Accept تحديثها؟

بعد أن يؤكد AMF إمكانية بقاء UE مسجلًا، يعيد نتيجة التسجيل المحدثة إلى UE عبر Registration Accept. وفق نتيجة الشبكة، قد تتضمن الرسالة معلمات مثل Allowed NSSAI وT3512 وTA List، وعند الحاجة 5G-GUTI جديدًا.

يكتسب T3512 أهمية خاصة في تحديث التسجيل الدوري. إذا قدم AMF قيمة جديدة، فيجب أن يستخدمها UE في الدورة الدورية التالية. وإذا لم تُرسل قيمة جديدة، فيمكن لـ UE الاستمرار في استخدام الإعداد المخزن. يسمح ذلك للشبكة بتعديل سلوك التسجيل الدوري بمرور الوقت بدل تثبيت الفاصل الزمني دائمًا داخل الجهاز.

تستمر TA List في Registration Accept في تعريف منطقة التسجيل الحالية لـ UE. وعلى الرغم من أن التحديث الدوري نفسه لا يُشغَّل بسبب الخروج من هذه المنطقة، فإن تفاعل تسجيل ناجحًا يظل يتيح للشبكة تزويد UE بأحدث معلمات إدارة التنقل.

إذا احتوت Registration Accept على 5G-GUTI جديد، فيحتاج UE إلى تأكيد الاستلام الناجح للهوية المؤقتة عبر Registration Complete. وإذا لم يخصص AMF 5G-GUTI جديدًا، فإن غياب Registration Complete لا يعني تلقائيًا وجود فشل. يجب تفسير مسار الإشارات وفق عناصر المعلومات في Registration Accept التي تحتاج فعليًا إلى تأكيد.

وهذا يوضح أيضًا أن تحديث التسجيل الدوري أكثر من مجرد آلية للحفاظ على النشاط. فهو يظل جزءًا من إطار 5GMM Registration، ويتيح للشبكة إعادة مزامنة معلمات التنقل المتعلقة بالتسجيل بدل الاكتفاء بالتحقق من قدرة UE على الاستجابة.

كيف يمكن التحقق من تحديث التسجيل الدوري في مسار الإشارات؟

عند استكشاف مشكلات تحديث التسجيل الدوري، لا تكون البداية الأكثر فاعلية هي البحث عن إشارات AUSF أو UDM. الأفضل هو تتبع السلسلة T3512 → حالة UE → Registration Request → سياق AMF → Registration Accept.

إذا لم يبدأ UE أي تحديث دوري بعد التسجيل، فتحقق أولًا مما إذا كانت Registration Accept تحتوي على قيمة T3512 صالحة. إذا كان T3512 معطلًا أو مضبوطًا على صفر، فلا ينبغي توقع تحديث دوري. وإذا كانت القيمة صالحة، فتأكد من أن UE دخل فعلًا حالة 5GMM-IDLE المناسبة ومن عدم حدوث أي تفاعل NAS قد يكون أوقف المؤقت أو أعاد تشغيله أو حدثه.

إذا أرسل UE رسالة Registration Request لكن AMF تعامل معها كتسجيل أولي، فتحقق من نوع تسجيل 5GS و5G-GUTI. إذا تعذر على AMF ربط 5G-GUTI بسياق UE موجود، فقد يدخل الإجراء في مسار أكثر تعقيدًا لاستعادة الهوية أو إعادة التسجيل.

إذا تم التعرف على Registration Request بصورة صحيحة ثم ظهر بعد ذلك إجراء مصادقة كامل، فهذا وحده لا يثبت وجود مشكلة. يجب فحص NAS Security Context الحالي ومعرفة ما إذا كانت الشبكة قررت إعادة تنفيذ المصادقة وفق سياستها الأمنية.

إضافة إلى T3512 في جانب UE، يستخدم AMF آلية مهمة لمراقبة إمكانية الوصول في جانب الشبكة، وهي Mobile Reachable Timer (مؤقت إمكانية الوصول المتنقل). بالنسبة إلى UE مسجل بصورة طبيعية، يكون هذا المؤقت في جانب الشبكة أطول من T3512، وعادة تكون العلاقة الافتراضية T3512 مضافًا إليه أربع دقائق. يبدأ AMF مؤقت Mobile Reachable Timer بعد تحرير اتصال إشارات NAS ويوقفه عندما يعيد UE إنشاء اتصال NAS.

تعمل الآليتان معًا:

       T3512 في جانب UE: يحدد لـ UE متى يجب أن يعود لتحديث التسجيل
       Mobile Reachable Timer في جانب AMF: يراقب ما إذا كان UE سيظهر مجددًا ضمن الفترة المتوقعة    

إذا لم يتصل UE بالشبكة لفترة طويلة، فإن Mobile Reachable Timer وآلية إلغاء التسجيل الضمني اللاحقة تتيحان للشبكة الأساسية التعامل تدريجيًا مع UE لم يعد من الممكن تأكيد إمكانية الوصول إليه، بدل الاحتفاظ إلى أجل غير مسمى بسياق تسجيل قديم.

لذلك فإن الهدف الحقيقي من تحديث التسجيل الدوري في 5GC ليس «إعادة التسجيل كل بضع عشرات من الدقائق». بل يتيح لـ UE الذي يبقى خاملًا فترة طويلة ولـ AMF إعادة إنشاء فهم مشترك لحالة التسجيل بصورة دورية: UE ما يزال موجودًا، وعلاقة التسجيل الحالية ما تزال صالحة، ويمكن الاستمرار في استخدام معلمات التنقل ذات الصلة خلال الفترة التالية.

في تحديث التسجيل الدوري ضمن 5GC، يعمل T3512 في جانب UE وMobile Reachable Timer في جانب AMF معًا لمراقبة إمكانية الوصول إلى UE والمساعدة في استكشاف فقدان التحديثات الدورية أو بقاء سياق تسجيل قديم
في تحديث التسجيل الدوري ضمن 5GC، يعمل T3512 في جانب UE وMobile Reachable Timer في جانب AMF معًا لمراقبة إمكانية الوصول إلى UE والمساعدة في استكشاف فقدان التحديثات الدورية أو بقاء سياق تسجيل قديم

الأسئلة الشائعة

هل T3512 ثابت عند 54 دقيقة في كل شبكة 5G؟

لا. أربع وخمسون دقيقة هي القيمة الافتراضية التي حددها 3GPP، لكن AMF يمكنه تعيين قيمة أخرى وفق إعداد الشبكة وسلوك UE ومعلومات الاشتراك والسياسة. يجب أن يعتمد تحليل الإشارات واستكشاف الأعطال دائمًا على قيمة T3512 التي استلمها UE فعليًا بدل افتراض أنها 54 دقيقة دائمًا.

إذا كان لدى UE حركة بيانات طبيعية خلال فترة الـ54 دقيقة، فهل سيرسل تحديث تسجيل دوريًا عند الدقيقة 54 بالضبط؟

ليس بالضرورة. في التشغيل العادي لـ T3512، يؤثر الدخول إلى 5GMM-CONNECTED في المؤقت الدوري، وقد يعاد تشغيل المؤقت عندما يعود UE لاحقًا إلى IDLE. لذلك لا يمكن التنبؤ برسالة Registration Request التالية بمجرد إضافة 54 دقيقة إلى وقت إكمال التسجيل الأولي. كما يختلف سلوك التوقيت عندما يكون مؤقت التسجيل الدوري الصارم مفعّلًا.

هل يتطلب كل تحديث تسجيل دوري مشاركة AUSF وUDM وPCF؟

لا. إذا بقي AMF المُقدِّم للخدمة من دون تغيير، وكان سياق UE وسياق الأمان الحاليان صالحين، ولم تكن هناك حاجة إلى تحديث معلومات الاشتراك أو السياسة، فيمكن أن يبقى الإجراء قصيرًا جدًا. يعتمد استدعاء AUSF أو UDM أو PCF أو NRF على سياق UE وتنفيذ الشبكة في ذلك الوقت. ولا ينبغي اعتبارها وظائف شبكة إلزامية في كل تحديث تسجيل دوري.

هل ينطبق تحديث التسجيل الدوري على الوصول غير 3GPP مثل Wi-Fi؟

تنطبق آلية تحديث التسجيل الدوري المعتمدة على T3512 على UE مسجل في 5GS عبر وصول 3GPP. أما الوصول غير 3GPP، فيستخدم 5GS آليات أخرى مناسبة لإدارة التسجيل وإلغاء التسجيل، ولذلك لا ينبغي تطبيق سلوك T3512 المستخدم مع وصول NR مباشرة على Wi-Fi أو سيناريوهات الوصول غير 3GPP الأخرى.

المنتجات الموصى بها
كتالوج
خدمة العملاء الهاتف
We use cookie to improve your online experience. By continuing to browse this website, you agree to our use of cookie.

Cookies

This Cookie Policy explains how we use cookies and similar technologies when you access or use our website and related services. Please read this Policy together with our Terms and Conditions and Privacy Policy so that you understand how we collect, use, and protect information.

By continuing to access or use our Services, you acknowledge that cookies and similar technologies may be used as described in this Policy, subject to applicable law and your available choices.

Updates to This Cookie Policy

We may revise this Cookie Policy from time to time to reflect changes in legal requirements, technology, or our business practices. When we make updates, the revised version will be posted on this page and will become effective from the date of publication unless otherwise required by law.

Where required, we will provide additional notice or request your consent before applying material changes that affect your rights or choices.

What Are Cookies?

Cookies are small text files placed on your device when you visit a website or interact with certain online content. They help websites recognize your browser or device, remember your preferences, support essential functionality, and improve the overall user experience.

In this Cookie Policy, the term “cookies” also includes similar technologies such as pixels, tags, web beacons, and other tracking tools that perform comparable functions.

Why We Use Cookies

We use cookies to help our website function properly, remember user preferences, enhance website performance, understand how visitors interact with our pages, and support security, analytics, and marketing activities where permitted by law.

We use cookies to keep our website functional, secure, efficient, and more relevant to your browsing experience.

Categories of Cookies We Use

Strictly Necessary Cookies

These cookies are essential for the operation of the website and cannot be disabled in our systems where they are required to provide the service you request. They are typically set in response to actions such as setting privacy preferences, signing in, or submitting forms.

Without these cookies, certain parts of the website may not function correctly.

Functional Cookies

Functional cookies enable enhanced features and personalization, such as remembering your preferences, language settings, or previously selected options. These cookies may be set by us or by third-party providers whose services are integrated into our website.

If you disable these cookies, some services or features may not work as intended.

Performance and Analytics Cookies

These cookies help us understand how visitors use our website by collecting information such as traffic sources, page visits, navigation behavior, and general interaction patterns. In many cases, this information is aggregated and does not directly identify individual users.

We use this information to improve website performance, usability, and content relevance.

Targeting and Advertising Cookies

These cookies may be placed by our advertising or marketing partners to help deliver more relevant ads and measure the effectiveness of campaigns. They may use information about your browsing activity across different websites and services to build a profile of your interests.

These cookies generally do not store directly identifying personal information, but they may identify your browser or device.

First-Party and Third-Party Cookies

Some cookies are set directly by our website and are referred to as first-party cookies. Other cookies are set by third-party services, such as analytics providers, embedded content providers, or advertising partners, and are referred to as third-party cookies.

Third-party providers may use their own cookies in accordance with their own privacy and cookie policies.

Information Collected Through Cookies

Depending on the type of cookie used, the information collected may include browser type, device type, IP address, referring website, pages viewed, time spent on pages, clickstream behavior, and general usage patterns.

This information helps us maintain the website, improve performance, enhance security, and provide a better user experience.

Your Cookie Choices

You can control or disable cookies through your browser settings and, where available, through our cookie consent or preference management tools. Depending on your location, you may also have the right to accept or reject certain categories of cookies, especially those used for analytics, personalization, or advertising purposes.

Please note that blocking or deleting certain cookies may affect the availability, functionality, or performance of some parts of the website.

Restricting cookies may limit certain features and reduce the quality of your experience on the website.

Cookies in Mobile Applications

Where our mobile applications use cookie-like technologies, they are generally limited to those required for core functionality, security, and service delivery. Disabling these essential technologies may affect the normal operation of the application.

We do not use essential mobile application cookies to store unnecessary personal information.

How to Manage Cookies

Most web browsers allow you to manage cookies through browser settings. You can usually choose to block, delete, or receive alerts before cookies are stored. Because browser controls vary, please refer to your browser provider’s support documentation for details on how to manage cookie settings.

Contact Us

If you have any questions about this Cookie Policy or our use of cookies and similar technologies, please contact us at support@becke.cc .