Mapping tasks and response timeتوزيع المهام وزمن الاستجابة

Picture a phone camera taking a street photo. Three things must happen before the user sees a useful result: the photo is shrunk to the size the model expects (T1, image resize), a model finds the cars and people in it (T2, object detection), and a box is drawn around each one (T3, drawing the bounding box).

تخيّل كاميرا هاتف تلتقط صورة لشارع. قبل أن يرى المستخدم نتيجة مفيدة يجب أن تحدث ثلاثة أشياء: تُصغَّر الصورة إلى الحجم الذي يتوقعه النموذج (T1، تغيير حجم الصورة)، ثم يكتشف نموذج السيارات والأشخاص فيها (T2، اكتشاف الأجسام)، ثم يُرسم مربع حول كل واحد منها (T3، رسم مربع الإحاطة).

Those three ordered steps form a service pipeline. The pipeline says what must happen and in what order. It says nothing about where. The edge-to-cloud continuum offers device, edge, fog and cloud, and each task can land on any of them. Choosing a Layer for every task is called a Mapping, and the rest of this part compares four such choices for the same three tasks.

هذه الخطوات الثلاث المرتبة تشكّل خط معالجة الخدمة (service pipeline). يحدد خط المعالجة ما يجب أن يحدث وبأي ترتيب، لكنه لا يقول شيئًا عن المكان. الاستمرارية من الحافة إلى السحابة (edge-to-cloud continuum) توفر الجهاز والحافة والضباب والسحابة، ويمكن أن تقع كل مهمة على أي منها. اختيار طبقة (layer) لكل مهمة يسمى تعيينًا (mapping)، وبقية هذا الجزء تقارن أربعة اختيارات من هذا النوع للمهام الثلاث نفسها.

The baseline: everything on one cloud serverخط الأساس: كل شيء على خادم سحابي واحد

The simplest mapping puts all three tasks on one Server in a distant Cloud data center. The Client only sends the photo and receives the finished image. Call this Mapping 1; it is the yardstick the other three are measured against.

أبسط تعيين يضع المهام الثلاث كلها على server واحد في مركز بيانات cloud بعيد. العميل (client) يرسل الصورة فقط ويستقبل الصورة النهائية. سنسمي هذا التعيين 1، وهو المقياس الذي تُقارَن به التعيينات الثلاثة الأخرى.

Measuring what the user feelsقياس ما يشعر به المستخدم

To compare mappings you need one number that captures the user's experience. Start a stopwatch when the photo leaves the phone and stop it when the boxed image arrives back. That total is the Response time (RT), and it splits into three stretches: the request travels to the server (Latency 1), the server runs T1, T2 and T3 (the Processing time (PT)), and the result travels back (Latency 2).

لكي تقارن بين التعيينات تحتاج إلى رقم واحد يعبّر عن تجربة المستخدم. شغّل ساعة إيقاف عندما تغادر الصورة الهاتف، وأوقفها عندما تصل الصورة المؤطَّرة بالمربعات. هذا المجموع هو زمن الاستجابة (response time)، وينقسم إلى ثلاثة مقاطع: انتقال الطلب إلى الخادم (Latency 1)، وتشغيل الخادم للمهام T1 وT2 وT3 (زمن المعالجة (processing time))، ثم عودة النتيجة (Latency 2).

Neither latency term is a single number from nature. From Part 7 you know each Latency is the sum of Propagation delay, Transmission delay, Queueing delay and Processing delay along every link and router on the path (Kurose and Ross). L1 plus L2 is roughly the round-trip time you would measure with ping, and PT is extra time inserted in the middle.

لا يوجد حدّ من حدود زمن التأخير هو رقم ثابت من الطبيعة. تعرف من الجزء 7 أن كل latency هو مجموع تأخير الانتشار (propagation delay) وتأخير الإرسال (transmission delay) وتأخير الانتظار في الطابور (queueing delay) وتأخير المعالجة (processing delay) على كل وصلة وموجّه في المسار (Kurose and Ross). مجموع L1 وL2 يساوي تقريبًا زمن الذهاب والإياب (round-trip time) الذي تقيسه بأمر ping، وPT وقت إضافي يُدرج في المنتصف.

The examples here treat L1 and L2 as equal only for simplicity. In practice they can differ: the request is often a small upload while the response is a large annotated image, and transmission delay grows with the number of bits pushed onto a link. Every mapping below is just a different way of making these terms bigger or smaller, which is why the formula is the lens for the whole part.

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

The formula becomes a design argument once you put numbers in it. A client sits in New York and the server sits in a cloud data center in California. The request takes 70 ms to cross the country, the server works for 30 ms, and the reply takes another 70 ms.

تتحول المعادلة إلى حجة تصميمية عندما تضع فيها أرقامًا. عميل موجود في نيويورك والخادم في مركز بيانات سحابي في كاليفورنيا. يستغرق الطلب 70 ms لعبور البلاد، ويعمل الخادم لمدة 30 ms، ويستغرق الرد 70 ms أخرى.

Amdahl's argument, moved onto the networkحجة Amdahl منقولة إلى الشبكة

The disappointing result is not a quirk of these numbers. In 1967 Gene Amdahl pointed out that the part of a job you do not speed up places an upper limit on the overall gain, so effort on one part "is wasted unless it is accompanied by achievements" of similar size in the rest (Amdahl, 1967). Amdahl wrote no equation; the usual textbook form is below, where f is the fraction of time you improve and k is how much faster that part becomes.

هذه النتيجة المخيبة ليست مصادفة خاصة بهذه الأرقام. في عام 1967 أشار Gene Amdahl إلى أن الجزء الذي لا تسرّعه من العمل يضع حدًا أعلى للمكسب الكلي، لذلك فإن الجهد المبذول على جزء واحد "is wasted unless it is accompanied by achievements" (يضيع ما لم تصحبه إنجازات) بحجم مماثل في البقية (Amdahl, 1967). لم يكتب Amdahl معادلة، والصيغة المعتادة في الكتب أدناه، حيث f هي نسبة الوقت الذي تحسّنه وk هو مقدار تسريع ذلك الجزء.

With f = 30/170 and k = 2, the formula gives 1 / (0.8235 + 0.0882) ≈ 1.097, the same answer as the worked example. As k grows without bound the speedup approaches 1 / (1 - f), which is the 1.21x ceiling.

عندما f = 30/170 وk = 2 تعطي المعادلة 1 / (0.8235 + 0.0882) ≈ 1.097، وهي الإجابة نفسها في المثال المحلول. وكلما كبرت k بلا حد اقترب التسريع من 1 / (1 - f)، وهو سقف 1.21x.

In Mapping 1 the part you cannot improve is the network. Physics bounds L1 and L2, and Satyanarayanan notes that "the speed of light is an obvious physical limit on latency". The only large lever left is shortening the distance, which is exactly what Edge computing does. He concludes that relying on a distant data center is not advisable for applications that need end-to-end delays tightly controlled below a few tens of milliseconds (Satyanarayanan, 2017).

في التعيين 1 الجزء الذي لا تستطيع تحسينه هو الشبكة. الفيزياء تحدّ L1 وL2، ويلاحظ Satyanarayanan أن "the speed of light is an obvious physical limit on latency" (سرعة الضوء حد فيزيائي واضح لزمن التأخير). الرافعة الكبيرة الوحيدة المتبقية هي تقصير المسافة، وهذا بالضبط ما تفعله حوسبة الحافة (edge). ويخلص إلى أن الاعتماد على مركز بيانات بعيد غير مستحسن للتطبيقات التي تحتاج إلى تأخير طرفي إلى طرفي مضبوط بإحكام تحت بضع عشرات من الملي ثانية (Satyanarayanan, 2017).

So is Mapping 1 a bad design?إذن هل التعيين 1 تصميم سيئ؟

No. The same centralization that makes it slow for far clients is what makes it attractive. With one model in one Cloud deployment, every user gets the same model version, and an update is a single deploy. The client stays thin, since it only captures and displays. Satyanarayanan describes the benefit: "centralization exploits economies of scale to lower the marginal cost of system administration and operations" (Satyanarayanan, 2017). When demand grows, you rent more machines in the same region.

لا. المركزية نفسها التي تجعله بطيئًا للعملاء البعيدين هي ما يجعله جذابًا. مع نموذج واحد في نشر واحد على cloud، يحصل كل مستخدم على نسخة النموذج نفسها، والتحديث عملية نشر واحدة. ويبقى العميل خفيفًا لأنه يلتقط ويعرض فقط. يصف Satyanarayanan الفائدة: "centralization exploits economies of scale to lower the marginal cost of system administration and operations" (المركزية تستغل وفورات الحجم لخفض التكلفة الحدية لإدارة النظام وتشغيله) (Satyanarayanan, 2017). وعندما يزداد الطلب تستأجر أجهزة أكثر في المنطقة نفسها.

Whether distance is a problem depends on the service. For photo tagging, a few hundred milliseconds are fine and Mapping 1 is often the right call. For augmented reality or a multiplayer game, where a frame must react within milliseconds, every request paying the full Latency both ways is not acceptable.

كون المسافة مشكلة أم لا يعتمد على الخدمة. في وسم الصور (photo tagging) بضع مئات من الملي ثانية مقبولة، وغالبًا ما يكون التعيين 1 هو الخيار الصحيح. أما في الواقع المعزز أو لعبة جماعية عبر الشبكة، حيث يجب أن يستجيب الإطار خلال ملي ثوانٍ، فإن دفع كل طلب لكامل latency في الاتجاهين غير مقبول.

If the network dominates, the most radical fix is to delete it. Mapping 2 runs the whole photo pipeline on the phone. Nothing is uploaded, so there is no L1 and no L2, and the response time collapses to the processing time alone.

إذا كانت الشبكة هي المهيمنة، فأكثر الحلول جذرية هو حذفها. التعيين 2 يشغّل خط معالجة الصور كله على الهاتف. لا يُرفع شيء، فلا يوجد L1 ولا L2، وينكمش زمن الاستجابة إلى زمن المعالجة وحده.

That sounds ideal until you look at what PT now means. The Client Device has a small battery-powered chip, not a data center accelerator. Resize (T1) and drawing (T3) are cheap, but object detection (T2) is heavy. On weak hardware it takes far longer, and the whole time the processor draws power from the battery. In the lecture's layer model this is the Device stage at the very start of the continuum, before Mist, with no edge, fog or cloud involved, and it is the case with no Offloading at all: the weakest component keeps all the work.

يبدو هذا مثاليًا حتى تنظر إلى ما يعنيه PT الآن. جهاز (device) العميل (client) فيه شريحة صغيرة تعمل بالبطارية، وليس مسرّعًا من مسرّعات مراكز البيانات. تغيير الحجم (T1) والرسم (T3) رخيصان، لكن اكتشاف الأجسام (T2) ثقيل. على عتاد ضعيف يستغرق وقتًا أطول بكثير، وطوال هذا الوقت يسحب المعالج الطاقة من البطارية. في نموذج الطبقات في المحاضرة هذه هي مرحلة الجهاز (Device) في بداية الاستمرارية تمامًا، قبل الضباب الخفيف (mist)، دون أي حافة أو ضباب أو سحابة، وهي الحالة التي لا يوجد فيها تفريغ للحمل (offloading) إطلاقًا: أضعف مكوّن يحتفظ بالعمل كله.

The simulator makes the trade visible. Its all-device preset shows 0 ms of network but 440 ms of processing, while the all-cloud preset shows 159 ms in total. Removing two terms from a sum does not help if the remaining term grows past what you removed.

المحاكي يجعل هذه المقايضة مرئية. إعداده المسبق «كل شيء على الجهاز» يُظهر 0 ms للشبكة لكن 440 ms للمعالجة، بينما إعداد «كل شيء في السحابة» يُظهر 159 ms إجمالًا. حذف حدّين من مجموع لا يفيد إذا كبر الحد المتبقي أكثر مما حذفت.

What the user gains is not speed but independence. With no dependency on the network, the service keeps working with no signal. The raw data never leaves the device, which reduces privacy concerns.

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

Where it shows up: the smartwatchأين يظهر: الساعة الذكية

A smartwatch that notices you have started running is Mapping 2 in a product you can buy. The motion sensors stream data constantly, and the watch must decide on the spot. Apple's documentation, for example, says that for walking, running, swimming and other workouts "your Apple Watch senses when you're moving and alerts you to start the Workout app" (Apple Support). The page does not say where the detection runs, so treat it as an example of the feature, not as proof of an on-watch model. The general point stands: running the classifier on the Device keeps raw motion data private and works without a phone nearby, but it is bounded by battery life and a small processor.

الساعة الذكية التي تلاحظ أنك بدأت الجري هي التعيين 2 في منتج يمكنك شراؤه. حساسات الحركة تبث البيانات باستمرار، ويجب على الساعة أن تقرر في الحال. توثيق Apple مثلًا يقول إنه في المشي والجري والسباحة وتمارين أخرى "your Apple Watch senses when you're moving and alerts you to start the Workout app" (تستشعر ساعتك أنك تتحرك وتنبهك لبدء تطبيق التمرين) (Apple Support). الصفحة لا تذكر أين يجري الاكتشاف، فاعتبرها مثالًا على الميزة لا دليلًا على نموذج يعمل داخل الساعة. لكن الفكرة العامة صحيحة: تشغيل المصنِّف على device يحفظ خصوصية بيانات الحركة الخام ويعمل دون وجود هاتف قريب، لكنه محدود بعمر البطارية ومعالج صغير.

Toolkits exist precisely for this. Google's LiteRT (formerly TensorFlow Lite) runs trained models on phones and embedded boards and advertises "low latency and high privacy on billions of devices" (Google for Developers). The typical recipe is to train a large model in the cloud, then compress it until it fits the device, which attacks PT directly since it is the only term left.

توجد أدوات مصممة لهذا تحديدًا. LiteRT من Google (سابقًا TensorFlow Lite) يشغّل النماذج المدرَّبة على الهواتف واللوحات المدمجة ويَعِد بـ "low latency and high privacy on billions of devices" (زمن تأخير منخفض وخصوصية عالية على مليارات الأجهزة) (Google for Developers). الوصفة المعتادة هي تدريب نموذج كبير في السحابة، ثم ضغطه حتى يناسب الجهاز، وهذا يهاجم PT مباشرة لأنه الحد الوحيد المتبقي.

• Choose Mapping 2 when connectivity cannot be assumed: a run in the mountains, a flight, a basement.اختر التعيين 2 عندما لا يمكن افتراض وجود اتصال: جري في الجبال، أو رحلة طيران، أو قبو.
• Choose it when raw data is sensitive and should not leave the device, such as health signals.اختره عندما تكون البيانات الخام حساسة ولا ينبغي أن تغادر الجهاز، مثل الإشارات الصحية.
• Choose it only when the model is small enough that PT and battery drain stay acceptable.اختره فقط عندما يكون النموذج صغيرًا بما يكفي ليبقى PT واستنزاف البطارية مقبولين.

Mappings 1 and 2 sit at the two extremes: a strong server far away, or a weak processor with no network. Mapping 3 looks for the middle. It keeps a real server but moves it close, into the same building or a nearby telecom site, which runs all three tasks and sends the result back.

التعيينان 1 و2 يقعان في الطرفين: خادم قوي بعيد، أو معالج ضعيف بلا شبكة. التعيين 3 يبحث عن الوسط. يبقي على خادم حقيقي لكنه يقرّبه، إلى المبنى نفسه أو موقع اتصالات قريب، وهذا الخادم يشغّل المهام الثلاث ويعيد النتيجة.

Both halves of the formula improve at once. Because the Server is close, L1 and L2 are small. Because it is a real server rather than a phone, PT is moderate. The simulator's all-edge preset shows 10 ms of network and 136 ms of processing, so 146 ms in total. Satyanarayanan's cloudlet idea is this design: a small data center near users that "can run arbitrary code just as in cloud computing", where "proximity of cloudlets to end users is crucial" (Satyanarayanan, 2017). The work is still offloaded from the device, but to a nearby point on the continuum instead of the far end.

يتحسن نصفا المعادلة معًا. لأن server قريب، يكون L1 وL2 صغيرين. ولأنه خادم حقيقي وليس هاتفًا، يكون PT معتدلًا. إعداد المحاكي «كل شيء على الحافة» يُظهر 10 ms للشبكة و136 ms للمعالجة، أي 146 ms إجمالًا. فكرة cloudlet لدى Satyanarayanan هي هذا التصميم: مركز بيانات صغير قرب المستخدمين "can run arbitrary code just as in cloud computing" (يستطيع تشغيل أي كود كما في الحوسبة السحابية)، حيث "proximity of cloudlets to end users is crucial" (قرب هذه المراكز من المستخدمين أمر حاسم) (Satyanarayanan, 2017). العمل لا يزال مُفرَّغًا (offloaded) من الجهاز، لكن إلى نقطة قريبة على الاستمرارية (continuum) بدلًا من طرفها البعيد.

Proximity has two prices, and both follow from the same fact that made the latency low. First, limited geographic reach: an Edge site is close to some users precisely because it is far from everyone else, who either get no service or a long trip. Second, limited scalability: an edge site is small, a few servers in a closet or a cabinet, so it cannot absorb a large workload the way a cloud region can. Covering a country means many small sites, each managed separately, which gives back the centralization that made Mapping 1 easy to operate.

للقرب ثمنان، وكلاهما ينبع من الحقيقة نفسها التي جعلت زمن التأخير منخفضًا. الأول، محدودية النطاق الجغرافي: موقع الحافة (edge) قريب من بعض المستخدمين تحديدًا لأنه بعيد عن الجميع غيرهم، فهؤلاء إما لا يحصلون على خدمة أو يقطعون رحلة طويلة. الثاني، محدودية قابلية التوسع: موقع الحافة صغير، بضعة خوادم في غرفة صغيرة أو خزانة، لذلك لا يستطيع استيعاب حمل كبير كما تفعل منطقة سحابية. تغطية دولة كاملة تعني مواقع صغيرة كثيرة، يُدار كل منها على حدة، وهذا يتخلى عن المركزية التي جعلت تشغيل التعيين 1 سهلًا.

Where it shows up: the retail storeأين يظهر: متجر التجزئة

Cameras and shelf sensors in a store feed a server in the back office. It counts footfall, notices which products customers pick up, and tracks inventory as it changes. The decisions are local and time-sensitive: restock a shelf now, open a second checkout because the queue is growing. Sending every video frame to a distant cloud would add Latency and upload a lot of footage, so the edge server answers in the store.

الكاميرات وحساسات الرفوف في المتجر تغذي خادمًا في المكتب الخلفي. يعدّ هذا الخادم الزوار، ويلاحظ أي منتجات يلتقطها الزبائن، ويتتبع المخزون أثناء تغيّره. القرارات محلية وحساسة للوقت: أعد ملء رف الآن، افتح صندوق دفع ثانيًا لأن الطابور يطول. إرسال كل إطار فيديو إلى سحابة بعيدة سيضيف latency ويرفع كمية كبيرة من اللقطات، لذلك يجيب خادم الحافة داخل المتجر.

Now test the two weaknesses against it. Could that back-office box serve a branch in another city? No, its users are the cameras and staff in this store. That is limited reach. Could it absorb the peak traffic of a hundred stores on a sales weekend? No, it is sized for one store. That is limited scalability. The store is a good fit precisely because neither weakness matters for its workload.

الآن اختبر نقطتي الضعف عليه. هل يستطيع ذلك الجهاز في المكتب الخلفي خدمة فرع في مدينة أخرى؟ لا، فمستخدموه هم كاميرات هذا المتجر وموظفوه. هذه محدودية النطاق. هل يستطيع استيعاب ذروة حركة مئة متجر في عطلة تخفيضات؟ لا، فهو مصمم بحجم متجر واحد. هذه محدودية قابلية التوسع. المتجر مناسب تمامًا لأن أيًا من نقطتي الضعف لا تهم في حمل عمله.

So far each mapping put the whole pipeline in one place. But the three tasks are not equally demanding, so why should they share a layer? Mapping 4 splits the pipeline: the light tasks stay near the user and the heavy task runs one tier up. T1 (resize) and T3 (draw) run in the Edge layer, and T2 (object detection) runs in the Fog layer, which has more compute.

حتى الآن وضع كل تعيين خط المعالجة كله في مكان واحد. لكن المهام الثلاث ليست متساوية في متطلباتها، فلماذا تشترك في طبقة واحدة؟ التعيين 4 يقسّم خط المعالجة: المهام الخفيفة تبقى قرب المستخدم والمهمة الثقيلة تعمل في طبقة أعلى. T1 (تغيير الحجم) وT3 (الرسم) تعملان في طبقة الحافة (edge)، وT2 (اكتشاف الأجسام) تعمل في طبقة الضباب (fog) التي لديها قدرة حسابية أكبر.

Think of it as one logical service deployed in two physical places. The Service pipeline is now distributed, so the formula has to grow. Count the hops: client to edge, edge to fog, fog to edge, edge to client. That is four network crossings instead of two, and each task contributes its own processing term.

فكّر فيه كخدمة منطقية واحدة منشورة في مكانين فعليين. خط المعالجة (pipeline) أصبح موزعًا، فلا بد أن تكبر المعادلة. عُدّ القفزات: من العميل إلى الحافة، ومن الحافة إلى الضباب، ومن الضباب إلى الحافة، ومن الحافة إلى العميل. هذه أربعة عبورات للشبكة بدلًا من اثنين، وكل مهمة تساهم بحد معالجة خاص بها.

In the simulator's Mapping 4 preset, those crossings add up to 40 ms and processing to 56 ms, so 96 ms, the lowest of the four presets. The fog does T2 much faster than the edge, and that saving outweighs the two extra hops. NIST describes fog nodes as sitting "between smart end-devices and centralized (cloud) services" and says fog "minimizes the request-response time" (NIST SP 500-325).

في الإعداد المسبق للتعيين 4 في المحاكي، مجموع هذه العبورات 40 ms والمعالجة 56 ms، أي 96 ms، وهو الأقل بين الإعدادات الأربعة. الضباب ينفذ T2 أسرع بكثير من الحافة، وهذا التوفير يفوق القفزتين الإضافيتين. تصف NIST عقد الضباب بأنها تقع "between smart end-devices and centralized (cloud) services" (بين الأجهزة الطرفية الذكية والخدمات المركزية السحابية) وتقول إن الضباب "minimizes the request-response time" (يقلل زمن الطلب والاستجابة) (NIST SP 500-325).

What sharing a fog node buysما الذي تكسبه من مشاركة عقدة ضباب

Speed is only part of the case. Picture ten intersections in a smart city. Each traffic camera has a small edge box that resizes frames. All ten send them to one nearby fog server, which runs a large vehicle detection model for all of them and returns detections to each box.

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

1. Sharing: one detection model serves users of many edge nodes, instead of a copy squeezed onto each small box.المشاركة: نموذج اكتشاف واحد يخدم مستخدمي عقد حافة كثيرة، بدلًا من نسخة محشورة في كل صندوق صغير.
2. Capacity: the fog node has more processing power and storage than any single edge site.السعة: عقدة الضباب لديها قدرة معالجة وتخزين أكبر من أي موقع حافة منفرد.
3. Learning: the fog collects data from all the edge nodes, which keeps the model up to date, for example by retraining on new traffic patterns.التعلّم: يجمع الضباب البيانات من كل عقد الحافة، مما يبقي النموذج محدّثًا، مثلًا بإعادة تدريبه على أنماط مرور جديدة.

This matches how NIST frames fog. Fog nodes support "a common data management and communication system" and are organized in clusters by their "latency-distance to the smart end-devices" (NIST SP 500-325). Aggregation and coordination are the fog's job, which partly restores the centralization that Mapping 3 gave up, without going all the way to the cloud.

هذا يتوافق مع طريقة NIST في تأطير الضباب. عقد الضباب تدعم "a common data management and communication system" (نظامًا مشتركًا لإدارة البيانات والاتصال) وتُنظَّم في عناقيد بحسب "latency-distance to the smart end-devices" (مسافتها الزمنية من الأجهزة الطرفية الذكية) (NIST SP 500-325). التجميع والتنسيق هما وظيفة الضباب، وهذا يعيد جزئيًا المركزية التي تخلى عنها التعيين 3، دون الذهاب حتى السحابة.

What splitting costsما تكلفة التقسيم

• The fog layer introduces latency relative to Mapping 3: every boundary between layers adds its own latency, with all four delay components. The fog is still much closer than the Cloud.طبقة الضباب تضيف زمن تأخير مقارنة بالتعيين 3: كل حد فاصل بين الطبقات يضيف زمن تأخيره الخاص بمكوّنات التأخير الأربعة كلها. ومع ذلك يبقى الضباب أقرب بكثير من السحابة (cloud).
• Every byte that crosses a boundary may be billed. Cloud providers already charge this way: AWS states that "there is a charge for data transfer across Regions" and that "data transfer from AWS to the internet is charged" (AWS Architecture Blog). Those quotes are about regions and the internet, not edge to fog links, but the principle carries over.كل بايت يعبر حدًا فاصلًا قد يُحاسَب عليه. مزودو السحابة يفعلون هذا أصلًا: تذكر AWS أن "there is a charge for data transfer across Regions" (هناك رسوم لنقل البيانات بين المناطق) وأن "data transfer from AWS to the internet is charged" (نقل البيانات من AWS إلى الإنترنت مدفوع) (AWS Architecture Blog). هذان الاقتباسان عن المناطق والإنترنت، لا عن الوصلات بين الحافة والضباب، لكن المبدأ نفسه ينطبق.
• So split where a task shrinks the data. Resizing before sending means fewer bytes cross the edge to fog link, which is exactly why T1 stays at the edge.لذلك قسّم عند المهمة التي تقلّص البيانات. تغيير الحجم قبل الإرسال يعني بايتات أقل تعبر وصلة الحافة إلى الضباب، وهذا بالضبط سبب بقاء T1 على الحافة.

The four mappings are clean teaching cases. Practice is messier in one specific way: a dedicated fog tier is not always deployed, or identified, as a separate layer. In most cases, architects use two layers, Edge and Cloud.

التعيينات الأربعة حالات تعليمية نظيفة. الواقع أكثر فوضى في نقطة محددة: طبقة الضباب المخصصة لا تُنشر دائمًا، أو لا تُعرَّف دائمًا، كطبقة منفصلة. في معظم الحالات يستخدم المعماريون طبقتين، الحافة (edge) والسحابة (cloud).

NIST agrees that fog is optional: it "is not perceived as a mandatory layer", and "different usecase scenarios might have different architectures" (NIST SP 500-325). The claim that "most" architects choose edge plus cloud is the lecturer's observation from practice. No industry-wide statistic backs the exact share.

تتفق NIST على أن الضباب اختياري: فهو "is not perceived as a mandatory layer" (لا يُعدّ طبقة إلزامية)، و"different usecase scenarios might have different architectures" (سيناريوهات الاستخدام المختلفة قد تكون لها معماريات مختلفة) (NIST SP 500-325). أما القول بأن «معظم» المعماريين يختارون الحافة مع السحابة فهو ملاحظة المحاضر من الممارسة. لا توجد إحصائية على مستوى الصناعة تدعم النسبة الدقيقة.

The resulting design has the shape of Mapping 4 with the cloud in place of the Fog: T1 and T3 at the edge, T2 in the cloud. It borrows the strength of each earlier mapping for the task that needs it. Go back to the retail store. The back-office edge server makes the live decisions, as in Mapping 3, and the cloud trains new models and computes trends across the whole chain, using the centralization that made Mapping 1 attractive. Each task gets the Layer that suits it.

التصميم الناتج له شكل التعيين 4 مع السحابة بدلًا من الضباب (fog): T1 وT3 على الحافة، وT2 في السحابة. إنه يستعير نقطة قوة كل تعيين سابق للمهمة التي تحتاجها. عد إلى متجر التجزئة. خادم الحافة في المكتب الخلفي يتخذ القرارات الحية كما في التعيين 3، والسحابة تدرّب نماذج جديدة وتحسب الاتجاهات عبر السلسلة كلها، مستفيدة من المركزية التي جعلت التعيين 1 جذابًا. كل مهمة تحصل على الطبقة (layer) التي تناسبها.