Timeboxes in the refinement

The Time box events are:
1) Sprint Planning
2) Daily Scrum
3) Sprint
4) Sprint Review
5) Sprint Retrospective.

If you cannot estimate then you cant do sprint planning and not even the Sprint will get over with most of stories being incomplete.
To be on safer side then the development team should include only those stories which are estimated with definition of done.

Why isn't the Product Owner able to explain the items on the Product Backlog during Product Backlog Refinement?

If he or she needs the help of the Development Team to create PBI's which they *can* estimate, then the whole team should give their assistance.

It also sounds as though "Business Analyst" is a role in this case, and an antipattern which ought to be addressed.

It is not up to the BA to decide how much time is spent on refining an item, it's a team decision. The team need to have an understanding of what the PBI entails to be able to estimate it.
Possibly the BA need to prepare PBIs better before discussing them in refinement. I assume the BA either the PO or a member of the dev team? Generally, I think time-boxing is good. It helps keep focus and help you prevent waste. If your refinement sessions take forever you need to discuss why and consider how this time might be reduced. Scrum is quite clear that roughly 10% if the time in a sprint should be used for planning activities such as refinement.
One technique that you might try is to time-box the discussion for e.g. 5 and after that the team votes (fist to five or similar) if they need to discuss the item further. If yes, continue the discussion for another 5 minutes, if no estimate and move to the next item.
This forces the team to consider if they know enough to estimate or not. In my experience, items are often discussed in too much detail before they are estimated which is wasteful.

Key purpose of Product Refinement/Grooming meeting is to -

1) Bring more clarity to PBI/Story in order to bring it closure to "ready" state

2) High level estimates( story points) as per the collective understanding of the participants/team basis "Relative Complexity" for the PBI/Story.

3) Identification of gaps/questions around the PBI. PO should then take away those questions/gaps and work to have them answered. Development team can play a major role by helping the PO in highlighting gaps/questions from functional and business value perspective (catch - Care should be taken that questions/gaps do not get drifted/biased from technical/solution mind set)

Refined stories (in accordance with Team's definition of "Ready") are taken as input for Sprint Planning meeting! Sprint planning meeting also provides opportunity ratify, validate and refine Estimation (Story Points) against each prioritized PBI.

Hi Micha,

As Rishi mentioned above, refinement meetings are not time-boxed, though they should not take more than 10% of a team's capacity. Looks like you BA is using time-boxing as an anti-overloading medicine :-).
You don't have to come up with estimations at the end of refinement meetings - these are required at the Sprint Planning event. And you cannot refine forever either. The recommended way is to refine in more details the items that are high on the backlog and less details for those which are lower. There is a possibility that the problematic user stories are too complex in which case the PO (sorry, the BA :-)) should invest some more in slicing them thinner.

Hope this helps,
Michael