The outer loop is the render loop (draw graphics), this frame rate is variable because it depends on the amount of CPU that this program receives from the system. If you computer is busy with other tasks, you game will receive small CPU time and the FPS will drop. Anyway, the loop keeps the game state where it is suppose to be, I mean that if an object is moving with constant velocity, you will see it always where it is expected to be. Just the game will skip some frames.
If there is enough CPU, some render frameworks, limit the FPS to a set value (example 60 FPS). Anyway, by definition, the outer loop is 1 frame (drawing function call).

About the inner loop, it is the Logic loop with fix step, it runs your game 16ms each time. How many? Those needed to reach to the current time.

The parameter 16 passed to the UpdateWorld function is to advance the game only 16ms. All the moving objects will be translated 16ms only. This step must be small enough to avoid the collision tunneling.

So the game loop is mainly

    while (1){

      int realTime = Gettime();

      UpdateWorld(realTime - simulationTime);  // but this is split in small steps of 16ms, to simplify the game physics
	  simulationTime = realTime;
	  
      RenderWorld();
      
    }

If everything in simulation was hard-coded to always assume 16 milliseconds for a step, then the argument 16 isn't needed for UpdateWorld().

If your frame rate is locked with VSync to 60 Hz, then you will always spend 16.6 milliseconds in the overall loop, and generally only run the inner loop once at a time. Except about one every hundred frames or whatever when the slight difference between vsync rate and world step rate accumulates to a full step, and you run the simulation loop twice. Or if your computer temporarily gets overloaded with other work, and falls behind, and then needs to catch up. (This was more common before quad-core was considered minimum spec.)

16 milliseconds is not enough to avoid tunneling in all cases, btw. It depends on the specifics of the simulation. Generally, for things that move fast, you'll want to use swept collision tests, rather than move-and-test. Some physics engines switch between modes, others always do swept (continuous) collision detection, and yet others will subdivide the step (taking, say, four 4ms steps) when they detect that things are close.